In the case of unit testing, I'm testing as many cases as I can that when I do
I'm also concerned in some cases that when I do
Z does not happen.
But for the sake of protection, I could also test that A, B, C ... do not happen either. And going that direction I could basically test a billion things that should not happen, and, in many cases, won't ever happen.
My question is, at what point do you think you're being too defensive, and when is it still considered useful ?
Let's use this bit of pseudo code as an example
Here are the tests I can have :
- A happens when X is true
- A does not happen when X is false
- B does not happen when X is true
- B happens when X is false
- C happens when X is true
- C happens when X is false
This is what I would do. But following that reasoning I could also test that
AnotherFunction is not called when X is true and false, just like I'm testing that C is called when X is true and false or that A/B are not called when X is false/true.
And going down that road I could literally test a million things that shouldn't happen for every test case I can find. Just to make sure next developers won't break the code.
In my example you might say "this is too obvious to be tested" but I'm sure you can imagine a point where code could be so fragile / complex that testing many different things that shouldn't happen could be done. My question is : should it be tested, and how far ?
Is there some kind of rule ? Am I missing something in the unit testing knowledge ?
On one side I feel that this is safer and offers a good defense against pretty much anything that I can think of. On the other hand this is far too defensive and abominable to maintain, while time consuming since you get to code 'anything that you could think of'.
Note that I applied this to function calls, but it extends to anything that follows the line of "testing things that should not happen".
Where should one stop testing in that direction?