On Wed 28th, ThoughtWorks & CcHub organized an event where Patrick Turley give a presentation on Unit Tests, Pair Programming, Continuous Integration (CI) and Continuous Delivery (CD). IMHO it was one of the best events at CcHub and I was quick to grab a front-row seat
While all the topics are very interesting I’ll like to talk more about Unit Testing especially because it generated a heated debate at the hub the next day with me at the epicenter defending Unit Testing ferociously against a horde of foes!
It started when concerns were raised that Unit Testing wouldn’t be feasible since we are usually under lots of pressure and that the added amount of code to be written would be a drag on the project. Why not just write the code and test manually as we usually do? Why do I have to write extra lines of code just to test it? Isn’t that a waste of time and energy? I have a deadline, and many projects to work on, is Unit Testing really necessary?
Being a developer I totally understand these concerns and I did share these concerns up until that meeting. I looked into Unit Testing with CakePHP & SimpleTest years back but didn’t adopt it because it looked unnecessarily complex to implement. Just imagining writing tests for an API I developed, or that magic class function that is the core of your application was almost depressing! After Patrick’s presentation I concluded that Unit Testing would actually make you develop faster, code better and make it easier to develop higher quality software.
So what changed my mind? What was the missing link I found? It’s basically the approach to Unit Testing. Like I mentioned earlier, writing unit tests for existing code is difficult. A better approach is test-driven development (TDD) i.e. write the tests for a functional unit of your appliation first and then code the functionality until it passes the tests. This approach makes it easier to write tests for your application.
While TDD addresses ease of writing tests I definitely don’t think anyone who has been concerned about how much more workload unit testing gives them is impressed. Rather, at this point I think they would be more pissed off. To answer that, I’ll say we need to think long term not short term. Yes, unit testing adds more workload and eats up your time in the short term but when you look at it long term you’ll see why it’s worth it because it saves you time, effort and improves software quality in the long run. Unit testing helps you easily identify issues before a catastrophe happens i.e. you deploy and your customer uses it, gets crappy output and is pissed off.
Unit testing helps improve the quality of your software and that in turn reduces the amount of time you need to spend debugging, offering customer support, fixing data corruption issues. Quality is cheaper in the long run. I’m always amazed by how many Toyotas and Hondas are on the road when I’m driving. Having driven both I know why people would rather pay extra to get these cars than buy a cheaper car.
Quality is important and is also a good marketing strategy. A satisfied customer is more likely to stay loyal and refer other people to you.
Would I use unit testing even though I’m the only developer on a project? YES!!! The more reason why I need it. I don’t know about you but I hate testing. Unfortunately in our world where a new feature can break 3 other features it’s essential that a comprehensive test be done every time the application is modified. I see Unit Testing helping me automate that process and thus free me to concentrate on the work to be done.
Unit testing is also crucial to Continuous Integration and Continuous Deployment.
My conclusion, yes unit testing & TDD requires lots of time, energy to kick-start and maintain especially in the short term, but in the long term it saves time, money & CPU cycles .