Testing right by testing the right thing

Before answering questions about unit testing I usually tend to ask some questions to get the broader picture – especially if the question sound strange.

Such question was asked by a teammate – he wanted to know if he can replace the behavior of a fake object while still calling the method replaced. This sounded a bit strange to me – either you want to fake an object or you don’t so I asked him if he happens to test the functionality of the same object he’s faking – he answered that no but he needs the method to run in order for the test to pass.

At first he insisted that he wants to test if a problem report in the system was closed twice as so he needs to count the times that the close method was called while still calling it. Next I asked him how does the user notice the issue, does our user care that he closes the report twice? obviously the user does not care. After further inquiry I manage to find that if a close operation is performed on an already close report an exception is thrown and the user does not get notification for the end of the running process. After we cam to that conclusion he managed to write a simple unit test that checks whether the user is notified in no time.

In retrospect I could have told him how to solve the issue he had using our Isolation framework of choice – the result would have a been a poorly written, fragile test.

Fragile Box by DHDesign, on Flickr
Creative Commons Attribution-Noncommercial 2.0 Generic License  by DHDesign


Happy coding…

Labels: ,