Too many numbers

For a long time now I’ve been telling people that there are only three numbers in computing:

• None
• One
• Many (and for our purposes Many will actually be Two)

Thus when testing if we cover these bases then that should be enough.  For example if testing that modifying properties on a record I might have a set of unit tests as follows:

• AddsNoProperties
• AddsOneProperty
• AddsTwoProperties

However even though records are by definition immutable in practice records managers sometimes have to amend them so we also need to test.

• UpdatesNoProperties
• UpdatesOneProperty
• UpdatesTwoProperties

Worse still they sometimes update records by removing information (typically due to a ‘misfile’) so we also need:

• DeletesNoProperties
• DeletesOneProperty
• DeletesTwoProperties

That’s nine tests not too bad.  Hold on what if in a single transaction we add some properties, update some properties and delete some properties?

• AddsNoPropertiesUpdatesNoPropertiesDeletesNoProperties
• AddsOnePropertyUpdatesNoPropertiesDeletesNoProperties
• AddsTwoPropertiesUpdatesNoPropertiesDeletesNoProperties
• AddsNoPropertiesUpdatesOnePropertyDeletesNoProperties
• AddsOnePropertyUpdatesOnePropertyDeletesNoProperties
• AddsTwoPropertiesUpdatesOnePropertyDeletesNoProperties
• AddsNoPropertiesUpdatesTwoPropertiesDeletesNoProperties
• AddsOnePropertyUpdatesTwoPropertiesDeletesNoProperties
• AddsTwoPropertiesUpdatesTwoPropertiesDeletesNoProperties
• …

If you work it out that’s 54 tests.  That’s too many.  We use xUnit so as well as Facts (xUnit tests) we have Theories (xUnit ‘data-driven’ tests) so maybe we really have one ‘theory’.

• AddsSomePropertiesUpdatesSomePropertiesDeletesSomeProperties

It will have fifty four examples, so while its better its still long to run and set up.  It smells of hidden complexity.

Hold on do we really have three numbers?  I don’t think so in fact we may have only one number:

• Some, and for our purposes this can be defined as any number greater than the minimum value and less than the maximum value.

In addition we probably have two edge cases:

• Minimum value, which we can assume as zero.
• Maximum value, which if we assume is two we can easily handle.

For this to be useful we need to be working with a collection of separate things, that is they must all be homogeneous and independent.  If they are not homogeneous then we need to treat each separately and if they have dependency on each other then which one we change becomes important.  However when using collections, e.g. lists, arrays, dictionaries, this is nearly always the case.

So this means I can now have a single test so long as I have enough things in my collection to allow for each action. I choose to split my actions and end up with three tests based on an object with two properties.

• AddsSomeProperties, using one existing property and adding one new property.
• UpdatesSomeProperties, using two properties and updating one and not the other.
• DeletesSomeProperties, using two properties and deleting one and not the other.

This is quick and easy and covers all the bases, except for those pesky edge cases.  However if these are important, e.g. deleting all properties, then we can convert our facts into theories and test for them.

So in this case we don’t have three numbers, in this case we only have one number:

• Some

Happy testing

Sebastian