5 Good (or not-so-good) reasons why programmers don’t test their code

Do you want to make a programmer’s day miserable? Ask them to do any of these:

• Go to the office
• Document
• Test

We will argue the 3 have something in common: they are useless.

Coming to Testing, in particular, I always remember this interaction a programmer colleague of mine had with his client:

The programmer was developing some code to download a file. When he finished, he sent the program’s result (the downloaded file) to the analyst (his client) to validate the information. A few minutes later, the client came to our office and asked him:

C: Jim, have you tested the file before sending it to me?

P: Of course!!

C: But it’s empty!!!

P: Well… I tested that the file was downloaded, but I haven’t opened it.

I agree that Jim went too far. Considering the project’s pressure and multiple developments going on when coming closer to the deadline, it’s understandable to miss some tests. However, I must recognize that our level of Testing is often low, even when we are not under pressure at all. Why is that?

To be honest, we do have some reasons for our mediocre tests. They may not be good ones, but they exist.

Our reasons

I challenge you to ask as many developers as you want; you won’t find anyone who tells you they like testing.

We enjoy thinking of a solution, we enjoy writing the code, and we even enjoy knocking our heads for hours looking for the root cause of an error, but we still see testing as a nightmare. I’ve worked in projects with dedicated testing teams, and they hated us. The feeling was reciprocal.

Trying to rationalize our posture, these are the reasons I find:

1 - It’s a Lose-Lose situation

In the best case, we won’t find any errors, meaning it was a waste of time. In the worst case, we will have 2 jobs: Testing and correcting every issue we find.

Imagine that we make an enormous effort to meet the impossible deadlines. Finding errors will only set us back. However, when we deliver, we reset the timer (I know, it’s probably a short-term mindset).

2 - We are optimists

We know we make mistakes. But we bet they are few and those specific scenarios will never happen.

Why would we waste time verifying and correcting errors that may never manifest?

If everything goes wrong and some time later they discover an issue that caused a significant impact, we still have the chance to no longer be in the project when the error is identified.

3 - We don’t know how to test it

This is painfully true.

We know how to program but not how to use what we program. Worse, no one in the entire building chain (user, business analyst, functional analyst, programmer, and tester) knows how to test it. Of course, everyone will point at the developer when errors are identified after the go-live, but we are the last ones to blame for those errors.

Business or functional analysts rarely share the possible scenarios to test. Additionally, we often don’t have enough data or the tools to create it.

4 - We are vindictive

The functional analysts usually send half the information we need to do the development.

We receive 5 paragraphs saying nothing and need to create a program out of them. To make it worse, we assume the entire project’s delay because every eyeball is on the implementation, but no one cares about the intermediate milestones (e.g., the designing and specification phases). When these situations happen, we must work overtime. And honestly, that makes us angry.

Returning the program without testing it is our little revenge (Ask Jim about that)

5 - Testing has no limits

We are bad at making decisions, which makes testing a never-ending activity.

We start listing cases, but the list only grows. From the normal flow until the most twisted, never-will-happen scenario. They are impossible to test, so we get a few “happy” cases and another completely unlikely.

If the samples look good, we assume everything in the middle will work, too.

Final thoughts

Jokes apart, Testing is as necessary for the project as disgusting for us.

Fellow programmer: Don’t let the humorous tone of this article mislead you. If you resonate with the above reasons, overcome the temptation and test your stuff.

Our lack of testing draws a veil over our lack of understanding of what we are doing.

On the other hand, good testing prevents rework, delays, stress, and potential big issues.

Do it for your client, project, industry, and, most importantly, for you. That’s how you will stand out from the competence.