Why bother writing unit tests?

3 07 2011

It’s funny to me how much of a fait accompli unit tests, continuous integration and agile methodologies have become. And, how those outside the scene understand so little of the intrinsic value. The more I talk with those developers on the outside, it becomes apparent just how wide the gap has become.

You see, I was never a fan of unit tests. Never.

Like many during the dotcom boom, I cut my teeth as a web developer, surrounding myself with clients and designers. I thought I was the bees knees. Why would I bother writing tests that would have to be refactored along with my code?

Deep down, I knew there was value. I knew it. There was no way that so many talented and capable developers were advocating their use if there wasn’t some significant value-add. But writing those tests felt like going to the dentist – and damn it if I was going to go willingly.

Soon enough, I found myself cornered into writing them. I gnashed my teeth, wrote the code, and then pointed and laughed gleefully each time I was forced to refactor. “See!” “See!” I would shout emphatically, and then blithely announce that the rest of my day was now effectively gone.

Initially, I saw test writing as most newbies do – as a way to ensure my code still worked as prescribed given an ever-changing system. I had my doubts to the effectiveness of such a principle, but I kept them to myself.

Then I thought – OK, so the PM wants these tests so they can sell it to the client. Work done, tests done – acceptance tests passed. “Done done”, and all that jazz. Makes sense, right? If you’re going to go agile, you better be able to ensure you’re actually building something every sprint, rather than just tinkering away and demoing little POCs.

It soon became apparent however, that I’d seriously underestimated the practice. Most of the discussions around software development in the post-web world – such as dependency injection, inversion of control and the problem with global state (ie. statics) – started to have a lot more meaning. I could no longer use aggregation or static singletons as helpers – even if I wanted to. Everything had to be injected and mocked, and the dependencies themselves had their own unit tests. Loose coupling became less of a nice-to-have, and more of a must-have.

It all suddenly made a lot of sense. My unit tests were enforcing best-practices on me and were actually helping me create my classes. Encapsulation, separation of concerns – each class had its purpose and my tests helped ensure that they remained that way.

Of course, I still find myself refactoring. I wouldn’t be much of a coder if I didn’t. You know what though – I’m finding it a lot less painful than it used to be. Everything is a lot more compartmentalised, and the code is self-describing. It’s no wonder there are scores of developers evangelising test-driven development (and, consequently, a counter-culture warning against over-dependence on test coverage).

If you don’t write unit tests, do yourself a favour. Start.



9 responses

3 07 2011

I agree with your sentiments, certainly cleaner code coming from TDD.

However, you inadvertently touched on something I find quite cheesy and disturbing. The ‘scene’ . There is one big fat group think going on, perpetuated and accelerated by social media.

3 07 2011
Justin J. Moses

@Sativa – scene mightn’t have been the best choice. Perhaps movement?

Nevertheless, there are plenty of people working outside this movement who see little value in the methodologies we evangelise. The more the “group think” matures and evolves, the more isolated those outside it become. By highlighting the value-add in unit testing for example, we come a step closer to rapprochement.

4 07 2011

Ah, the rapprochement. Once that occurs there can only be entropy and disease, like inbreeding.

Those that don’t think and act like the group will be ostracized. Original ideas and innovative thinking will be perceived as criticism. The group will only employ and interact with others in the group.


4 07 2011
Justin J. Moses


6 07 2011
Who struggles embracing unit testing? « kenfaw.com

[…] I want to share with you a blog post that I just loved reading over the weekend: “Why bother writing unit tests?” by Justin J. […]

8 07 2011
Marcus Stade

I still don’t like writing unit tests. Don’t get me wrong, I like the value they add, I just don’t like the actual part of writing them. There’s often way too much boiler plate involved in writing the tests, at least in the as3 world.

I also don’t like unit tests that fail at their very task: testing a unit. Many tests I come across actually test a system of units working together. This can be useful, but when such a test fails because a collaborator unit in the test is broken, I cringe a bit. Maybe I’m just too pedantic.

8 07 2011
Marcus Stade

Sorry for the double post, your blog made me think the comment wasn’t submitted correctly. (Yes I’m going to blame the software thankyouverymuch.)

8 07 2011
Justin J. Moses

And here I was thinking it was just Swede’s and technology that didn’t mix 🙂

8 08 2011
Who struggles embracing unit testing? » looseneurons.com

[…] I want to share with you a blog post that I just loved reading over the weekend: “Why bother writing unit tests?” by Justin J. […]

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

%d bloggers like this: