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.

Saturday, 19 March 2011

The audacity of hope

There was an article online stating why hope driven development is bad, Forget about Hope Driven Development (HDD), the cancer of software development. It is true that code quality and frequent demos are key to good software. That is the heart of agile development.

However sometimes we live in a less than perfect world. We may be put on projects where you are maintaining a code base written by 10 different people who have left the team.  You are now pressured by client demands to release a fix to the code base, whether that be a new column in the grid or some change to an interface. You make the change and now what? You release to a test environment and it works. You release to for QA and user sign off, great. Now you release it to production. Will your small change miss some corner case that is only possible in production that everyone couldn't test because you couldn't load that certain data into the database because another team was using it to test. You don't know. Are you gonna stop the release for this one small non show stopper bug? Here enters hope.