In the years I have been developing software, mostly web-focused, something was always missing: Unit testing. This was due to have been in companies whose culture abhorred anything that leads to delays, even justified. Something that could not be easily justified, cost-wise, as an advantage would be throw out the window.

My experience is limited to personal projects with perfect world requirements. So, in the end, I consider myself as a beginner on unit testing.

Where to start? I can analyze — and have analyzed — projects with unit testing implemented but nothing replaces hands-on experience in real projects with users and it’s edge cases. Glorified “hello worlds” do not count.

Going back a little, I understand the advantages of unit testing. I’ve seen projects with testing implemented and the benefits it’s bringing to the table, but it’s been impossible to convince management of its importance — and even other senior developers. Maybe I’m not good at communicating the pros and cons.

Finally, the other issue that unit testing brings. Testing is like digital security. Whoever is responsible for this will always be in an ungrateful position to defend. When everything is going well, that unit testing is doing its job properly and the devs reap the benefits someone will probably say — or at least think:

Why are we wasting time with unit testing if everything is going so well? Why am I paying you?

Or even when the inevitable bugs occur:

Why are we having problems? I thought we had unit testing. Why am I paying you?

This is aggravating.

One time I was meeting the teams on a new company that, eventually, I joined and I remember asking “Do you do unit testing?”. The happy answer was “of course”. I was happy that I would be joining a company where I could get experience with unit testing on real-world projects. Little did I know he was referring to end-user testing. There was a team dedicated to testing entire user processes, from start to finish, to make sure everything was according to the requirements. This was good to have, but it was not unit testing. I later found that this company had an annoying habit of using industry standard names that meant something completely different inside the company. Consultants? = Glorified salesmen.

Articulating the advantages seems hard when even seasoned devs don’t want or care about unit testing. In real life, we also have to take into account company policy, personal interests — I want this project done ASAP! — which usually means getting closer to that bonus.

What are the usual pros? Let’s list them.

• Finds bugs early — The sooner a bug is found, the less likely it appears on production.
• Improves code quality and readability — A big advantage for big projects.
• Facilitates changes giving greater confidence to the developer that his changes did not break existing functionality, therefore…
• … boosts developer productivity.

Sum all of the above and you have the biggest pro since it reduces costs in the medium to long-term.

I can analyze projects with unit testing implemented but nothing replaces hands-on experience in real projects with users and it’s edge cases. Glorified “hello worlds” do not count.

What are the downsides? Let’s take a look:

• Does not guarantee bug-free code. This is the obvious one, but somehow some people believe unit testing to be magical.
• Time-consuming. Same as saying it costs more. Can’t release the project on time, or the project must have features cut. Managers/Clients don’t like to hear that.
• Unit tests can/will have bugs. This one is down to the quality of the dev team. Have less discipline here and you will get in trouble.

It boils down to cost. A company culture that does not allow a developer to fail will not have unit testing. If you cannot count on your teammates to help, you will not have unit testing. If your company only sees you as a row on an excel spreadsheet, that means you will actually get burned with unit testing (cost) and then you will not have unit testing.

After reading much about unit testing the greatest advantage I see is that it makes us focus and reflect on the code written. If your code is too big or hard to read, you will most likely refactor it. In a team, this will lead to increased productivity with higher quality code bases. As a developer, I don’t need any more reasons to like unit testing.