Always test these 5 conditions in software

Just wanted to remember you about 5 classic, yet very important conditions you should verify your software for. And I strongly recommend you to remember and apply them everywhere in your tests, because they are really helpful in search of unexpected behaviors.

Let’s get started!

1. NULL (EMPTY)

Item is not set at all.
Not-a-software examples of NULL: you have no children at all; you have no boyfriend/girlfriend at all.

This is often a ‘broken’ or unexpected case. But it must be handled gracefully by the system. Some examples:

URL parameter “id” is declared, but not set:

http://example.com?id

Config parameter “max_size” has no value:

max_size=

There is no ”name” key in JSON object, but it was expected:

{'id': 42}

No JSON object returned in HTTP 200 OK response, but it was expected:

.

NULL. Nothing. You expected, that something must be there, but Oops!
Remember this case: NULL.

2. ZERO

Item value is Zero.
Not-a-software example of ZERO: you have no children, but you with your wife/husband expecting a baby; you have no girlfriend/boyfriend, but you are going to a date now.

Zero — is a special case, because it can cause unexpected system behavior, affecting true/false conditions verification in IF-ELSE, WHILE statements, division by zero exceptions, etc. Some examples:

Value is zero:

a = 0

List (massive) has zero elements:

a = []

Dictionary (named list) has zero elements:

a = {}

Zero of anything often causes an error. Remember this case: ZERO.

3. ONE

One item.
Not-a-software example of ONE: you have 1 child; you have a boyfriend/a girlfriend.

URL parameter has one value:

http://example.com?id=42

JSON object has one ‘id’ key:

{'id': 42}

Just a normal case. Almost everyone handles it. A smoke test.

4. TWO+

A pack of items. Duplicates also.
Not-a-software example of ONE: you have 2+ children; you have 2+ girlfriends/boyfriends.

Two items. Three… Five…
If you will be able to handle 2, then you, with a high probability, will be able to handle 3 and 5 and more. But 2+ children is not the same as 1 child, obviously… But 2 children —is almost the same parallelism, as with 3 and more. Got the point? Some examples:

URL parameter has two values:

http://example.com?id=42,43

JSON object has two ‘id’ keys with a value of different type:

{'id': 42, 'id': '43'}

It’s also easy to play with NULLs here:

http://example.com?id=42,,,

or this way (just add a comma — and your JSON parser may get down):

{'id': 42,}

Common scenario: system expected a single value, but a list has been received!

5. A LOT

Too many to handle.
Not-a-software example of A LOT: you have 100500 children; you have 100500 boyfriends/girlfriends :)

File is too big. Call is too long. All ports are busy. DoS attack. A LOT. A lot in time (speed). A lot in space (amount). Also a very important case: A LOT.

Conclusion

Systems should not crash in all cases listed above. Instead, they should intelligently and gracefully handle them and report responsively to an end-user about an error, if occurs.

Listed cases are very easy to remember as well: their number is the same as a number of fingers on your palm and a child / girlfriend analogy will help you emotionally!

Null, Zero, One, Many, Too many.

I hope you enjoyed reading and found it useful!
If so, please like to recommend others!

Thank you!