Hope Driven Development

Thursday 31 March 2011

Should I unit test?

The biggest reason why unit tests don't exist is because of one of the following reasons:
  • "I don't have time"
  • "It is too hard to write a unit test for"
  • "I'll do it after"
Umm, how will you know if your code will work? What will it display on the UI, what will it process on the server side? "Oh I pressed F5 in Visual Studio and it worked on my machine".  Fine that's sufficient if you are in school or straight out of university or you really don't know better (ignorance is bliss)

Automated "It works on my machine"
The time it takes to write a unit test to test an expected output is probably 5 minutes (create class, add test attributes on it, add test method, assert condition).  Now you have just automated the steps that you did to check the output on the UI. The beautiful part is that this is now automated and will always be tested. So now you are sure that it works. Two months down the road when someone changes the code not knowing about this text display and messes up your code that you worked hard on, they will be notified that it is broken. If you didn't write the unit test, you would have to manually check this test everytime! When another developer runs the code they will have to be aware of this feature and manually test it too.  It wastes everyone time and someone will miss it once or comment it out by accident. 

I don't know what I need to test
A lot of developers say this (mainly just junior ones). If I hear someone say this then I just reply what you trying to code. Most of the time they will say "Oh it should do this when this happens". Great!  That's all you need to know. Given, when, then aka behaviour driven development (BDD). If you structure your tests as given this scenario, when I do this, then this should be asserted, you can find yourself writing a lot more unit tests.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]



<< Home