Excuses for not writing automated tests

At some point in your career you will have to deal with someone who’s totally reluctant to writing/prioritising automated tests.
It may be a colleague of yours, a contributor to an open source project, a product manager, it may be even yourself!

Even if the reasons behind this resistance may be varied, I noticed that most of the times they stem from a common root: ignorance.

Let me clarify: I’m not here stating that not writing/prioritising automated tests makes someone an ignorant;
what I am saying is that the benefits deriving from having a solid set of automated tests makes it very difficult to decide not to have them in place, therefore only who is not aware of such benefits would decide not to write tests.

So, what are these benefits?

The Benefits

Having automated tests in place doesn’t affect engineers only, it affects what engineers make and how they make it: it affects the quality of the final product, and how the whole project is organised.
Therefore, let’s list how life would look like with a solid suite of automated tests in place from the product, the project, and the engineering standpoint.

NOTE: Keep in mind this list is not intended to be (and it’s really far from being) exhaustive, if you have some sound example please post it in the comments, I’ll gladly incorporate it here.

Product benefits

• A final user would notice a reduced number of new bugs (potentially none) affecting the existing product features
• A product owner\manager would enjoy a much faster and consistent quality assurance feedback when compared to manual QA (feedback measured in days usually shrinks down to hours)

Project benefits

A project\engineering manager

• would be able to deliver faster by unleashing the skills of multiple engineers working on the same project without blocking each other with unexpected behaviors
• would find that handing a project/task off to another team/engineer requires less documentation and support

Engineering benefits

An engineer

• would experience the joy of fearlessly refactoring and perfecting the existing solution
• would easily detect stable code, making its modularisation just a mere mechanical consequence

Usually the majority of the people agree with all the points above, but there’s always a “but”, a reason… an excuse I’d say… that prevents them from fully vesting automated tests.

Reasons excuses not to write tests

“Is it tested?”.

Over the last 3 years I found myself asking this very question many times in multiple occasions (in code reviews, pair programming sessions or during stand-ups\retrospectives, etc) to many different people. Nonetheless, the answers I got were surprisingly similar, so I grouped the most common ones by theme (or symptom if you want).

Time constraints

• I’ll do it later on
• We’re already late, there’s no time to write tests
• We should ship first
• This is just a “quick and dirty™” solution

Everybody is time-crunched, but taking shortcuts by not writing tests doesn’t save you time, on the contrary.
Let’s start from this: unless we have a reckless soul we need to test a feature going to production.
So, if we measure the time taken for a feature to be developed, tested, debugged and deployed by a team, the total time will be much less if we reduce the time taken for testing and debugging it to the minimum.
Therefore if we disseminate the code with automated tests as we go (not “later on”)

• we create a safe environment that prevents bugs from sneaking into our code
• we don’t waste human time by checking things that can be automated

In other words: the “quick and dirty™” solution is a myth. There’s just the “dirty” solution, or better the “dirty and time consuming” one.

Unclear roles and responsibilities

• This class/block of code didn’t have tests already
• QA will find the issues after we’re done
• Writing tests is responsibility of another team (usually QA)
• I will be the only person touching this code

If you are a one man band and you’re not thinking about working in a team ever in your life the latter may be a good one for you, but the majority of us work don’t work alone, therefore I’ll move over to the other points.

It’s quite common to find people “passing the buck” to others for something labelled as unpleasant, so getting rid of the responsibility of testing and focus only on “the real code” is just one example (supporting the live infrastructure — a.k.a. on-call policies — may be another).
But what happens when someone else is responsible for our actions? We don’t care anymore about the consequences of what we do, and this reflects on the quality (and the delivery schedule) of the final product.

Quality products are created by people who cares.
Engineers should be responsible of producing quality code.
Quality code is covered by automated tests wherever possible.
The QA team should be helping to test what cannot be tested automatically (localisations, graphics…).
“QA should find nothing™”.

Technical issues

• This class\feature is impossible\too difficult to test
• I don’t know what this class\function is supposed to do
• Tests make the build too slow

If like me you’re managing or leading an engineering team, this is something we should sink our teeth into.

We should establish some practices to allow our team to spot and resolve these issues as a team. Code reviews, pair programming, brown bag sessions are just a few examples.
If no one understands what a function is supposed to do we should expect this feedback to be given to the author of such function during a code review. Fail fast.

We should build our team’s engineering culture one practice at the time.
We should talk about practices, not policies. We should never mandate a practice unless we don’t have any other choice, and if we don’t have any other choice it’s probably a failure we should learn from.

Our team should have access to training material. Buy some books, some videos, send people to conferences, host some meetups.
If a class is too difficult to test we should expect an engineering team to find out why, come up with a solution, and share the knowledge within the team so not to fall into the same issue again.

We should provide our team with a healthy CI infrastructure and development machines that allow tests to be executed easily and frequently.
If some tests make the build too slow we should expect the author to notice while running them and optimise them for a good build time. Once more, fail fast and iterate until it works.
Automated tests are code, and engineers should be responsible of producing quality code.

Wrapping up

Most of the times deciding not to invest in test automation is not convenient for the business. Whether you’re an engineer, a product manager or even the business owner you should consider to establish this practice in your life\team\company as it pays back with a huge product quality improvement, a happier customers, and a happier development\product\QA teams.

I appreciate that we just covered the tip of this huge iceberg shaped topic, so I want to end with a question for you… what’s your excuse not to write tests?

Piergiorgio Niero
Director of Engineering @GSN London