≡ Menu
Pawel Brodzinski on Software Project Management

Best Practices: Unit Testing

Unit testing

We were talking with a couple of colleagues who I’m working with at the moment about value of unit testing. It was pretty unique group. I worked with the same people on a different product a couple of years ago. In terms of complexity and size both products are similar. What differentiates them is the way they were built.

Product A was just hacked. While building product B we used some of best engineering practices, unit testing being probably the most important in the context of our discussion.

The main visible difference was upgrades. With product A, every time we planned upgrade it was inseparably connected with fear. Fear that something would go wrong. Fear that strange errors would pop up in strange places. Fear that client’s marketing people will start yelling at client’s maintenance folks, who will start yelling at us.

Considering we were upgrading Product A every once a couple of weeks (during maintenance window in the middle of the night) it was like a constant uphill battle. Yes, we were trying to limit problems but it was more like a band aid for a broken leg. Everyone hated those dreaded nightly updates.

Now, we upgrade Product B with similar frequency. I think we faced some issues twice in like year and a half. No one is even stressed about those updates. It is just another station on our Kanban board. Definitely not the most painful one.

There were people from project management, development and maintenance involved in discussion and neither of us would like to get back to what we had with Product A. I can’t say exactly how much time we spend writing unit tests although if I had to guess I’d say at least a few times less than we’d have had to spend fixing recurring bugs and upgrade issues.

Let me stress once more: none of different folks involved in discussion had any doubts about the value of unit testing.

Note: I don’t try to make it about team happiness because of reduced load of worst kind of work, which is chasing and fixing bugs, or about client happiness because of reduced volume of issues. It’s just a simple business case. Invest some time in quality up front and get your ROI when you implement and maintain your software.

A final thought: I don’t say maintaining unit tests is easy or it always works without a glitch, but I don’t believe it doesn’t work in your case unless you’ve tried. And I mean really tried, not added a bunch of them and call the thing “boring.”

And if you want to yell at me because of writing such basic stuff, look around – I don’t know how about you but I still see a lot of projects which completely ignore existence of unit testing.

in: software development

3 comments… add one

  • Jeff December 13, 2010, 10:51 am

    Couldn’t agree with you more on this one. Hand-in-hand with unit testing goes a centralized continuous build server. You lose a lot of the power of unit tests when you don’t have team visibility into whether or not the product is in a viable form after the last commit. And obviously you can’t have that without source control. I think on a fundamental level, the critical troika is source control + build server + unit tests, in descending order of importance.

  • Pawel Brodzinski December 13, 2010, 11:55 am

    Now that you’ve mentioned source control, I’ve realized I don’t even consider building code without source control at all.

    And regarding continuous build, I fully agree (wrote about that as well).

  • Will December 22, 2011, 5:15 am

    Nice article. Just to give some balance, after many years, I’m still a skeptic. Good developers generally develop decent code, whereas poor developers develop poor code and poor unit tests that are often worse than nothing at all, their time would be better spent forgetting about testing and learning how to write decent code in the first place. Then, I’ve come across a number of great developers who have mocked and interfaced everything, modified the entire code design just so it plays nice with testing and left everyone else completely baffled by the complexity they have introduced. I want to believe, but I still value going back to basics and doing good old fashioned developer training, design and code reviews.

Leave a Comment