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 sstrange.
Such a question was asked by a teammate – he wanted to know if he could 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 '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, 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 came 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)