Is Unit Testing a waste of time?

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 :).


8 thoughts on “Is Unit Testing a waste of time?

  1. David Umoh says:

    Nice one Sola! i am exactly of the same opinion. I think one of the main differences between most of the software we develop here and those of most of the open source projects we enjoy is the issue of quality. Once you hear that the framework you want to use is supported by x and x number of unit tests and has excellent code coverage, there is this ‘peace of mind’ you have in using it. It’s the desire to have this same ‘peace of mind’ for the apps i develop(especially the ones that might require frequent changes even after going live) that drove me to start looking at TDD, Automated Deployment and the other components of continuous Integration. Thanks mehn!

  2. stefanhendriks says:

    One of the key factors why Unit Testing is nice, is that it proves your code is working as you would expect it. Hence it provides a safety net for refactorings. Another benefit is in order to test your code, it should be made ‘testable’ which I also interpret as “easy to use” (code wise). Eat your own dog-food principle is marvelous there.

    I believe Unit testing is actually faster than without. Mostly because unit tests keep you out of your debugger most of the time. The feedback loop is much much shorter.

    About TDD; I actually believe TDD is a very hard step to get into if you don’t test at all. It requires you to A) get into testing and B) totally do it ‘backwards’. I’ve seen it with a lot of people being a mental challange to do that at once.

    • sajayi says:

      Hello Stefan, thanks for you insightful comments. I’m getting into unit testing this weekend and will try starting using the TDD approach because I want to make my code testable from the foundation up. My challenge with adoption unit testing has always been that my code isn’t easily testable. Will let you know how it goes.

  3. sajayi says:

    Great article Stefan, loved the detailed examples. It really got me thinking if my approach is TDD or Test First. Basically I want to create a ticketing system. My unit tests would test if cases such as invalid tickets, used tickets, etc. are handled properly. In your opinion is this TDD or Test First?

    • stefanhendriks says:

      I would start with the happy path first. You need a set of business rules you want to implement, and with every step start with the ‘next most interesting test case’. You will probably start with very trivial tests, like a test that will force you to write a method that does not yet exist. (construction tests). But once you’re done with that, you will get into the business case. For each new step add a new test. Make sure you refactor your code and your tests in the Refactor phase. This way you keep doing TDD. Don’t try to think ahead too much. Its hard to do ‘real’ tdd, where you don’t even really start with a ‘production class’, rather start with tests (methods). The only way to learn is to experience and practice :). You could also get the hang of it by doing a kata. Ie, check the bowling game kata by robert c. martin. 🙂

  4. HMC says:

    So is this unit testing movement due to people using a lot of open source tools rather than proprietary software – where the producer is likely to have an internal software quality department and strategy ? Years of experience teach you what typically needs to be tested in any system. If you have a good reviewed functional specification , you design and code and constantly test that the spec is satisfied. Thus you are getting the production code built and tested as you progress. Not convinced by TDD except for simpler projects and inexperienced
    developers. A bit like spending time to see if the bricks will shatter before actually building the wall.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s