Agile Zone is brought to you in partnership with:

Dror Helper is an experienced software developer has written and designed software in various fields including video streaming, eCommerce, performance optimization and unit testing tools. He is passionate about programming best practices and all things software development, and has been a guest presenter at several user group meetings and ALT.NET events. Dror's blog can be found at http://blog.drorhelper.com where he writes about unit testing, agile methodologies, development tools, programming languages and anything else he finds interesting. Dror is a DZone MVB and is not an employee of DZone and has posted 57 posts at DZone. You can read more from them at their website. View Full User Profile

Testing right by testing the right thing

06.21.2011
| 4174 views |
  • submit to reddit

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.

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

 

Happy coding…

Published at DZone with permission of Dror Helper, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)