Why Nobody Tests Code in My Tech Job❓

Photo by Uby Yanes @ubyyanes on Unsplash

My code does not require testing.

I’m the perfect developer.

However, there are plenty of people on my team who are not up to my standards. They need to write tests but frequently don’t.

Here are the top 10 reasons I’ve heard that my teammates give to avoid testing their work.

“It works on my machine”

We’ve all done it. We might even run through some Unit Tests on our machine before pushing the code and expecting it to work.

My friend at the office insists that the problem isn’t with their code. They defend their technical chops at all costs.

I’ve never made a mistake, so the mistake must be the compiler on your machine.

They know that testing on a single machine isn’t enough. We all know that. Their pride gets in the way and stops them from achieving the coding greatness of The Secret Developer.

Remedy: Test your work on multiple devices, and have an automated testing setup.

“Manual tests are faster”

When I heard this excuse, I have to admit that I felt shocked. Developers skip automated repeatable tests for manual builds and insist that it is faster.

They claim that they could do this for every change they made to the codebase.

That’s impossible.

It should be obvious to all reading this; they were simply lying and putting untested code into production.

If manual tests are faster it is because you aren’t doing them right. Get with the program.

Remedy: Prize quality over speed.

“The code is untestable”

It is true that some code isn’t worth the time to test. At our place, the wrong call is frequently made on this though.

One of our programmers will insist that it is not possible to test network code because we can’t guarantee the state of our backend systems.

That single else path that catches a catastrophic error? We might not need a complete test on that one line, because we need to get the code out quickly.

But when a developer repeats something, it does not make it true.

Remedy: Get a better attitude.

“It takes too long to test”

This is true for some Agile sprints; we need to complete a feature and can show it in some sort of unfinished state during the sprint review. Production code however should be a different matter altogether. The coder that said this, seems to never have enough time to do things well, which should not be a surprise to anyone reading this blog.

You should produce good code production or not, no?

Remedy: Get more time by doing things better.

“Bad requirements”

It is actually quite valid to ask, how you can make sure that your code conforms to the specification if you don’t know what the specification actually is. The requirements for the software should be set in stone (well, a kind of stone specialized for Agile people) before a single piece of code is written.

How can we test it, if we aren’t sure what the code is doing?

No need to test, my code is perfect.

The answer for testing is to compromise. The level of compromise should leave all parties happy, and lead to workable, shippable software but in no way does it exclude the principle of unit testing, which is about testing the code in manageable chunks. That is, this excuse really doesn’t make any sense when you are coding using unit testing (as indeed you should be).

I should say that when I hear this excuse at work the problem is seldom the requirements. Usually, the developer has misread them or (in a case I’m thinking about) not read them at all. I hope you don’t work with a developer like that.

We all seem to work with developers like that.

Remedy: Compromise.

“The code doesn’t change”

The only certainty in software development is change, so I felt really surprised when a fellow developer claimed their code never changed. The requirements change, the software pivots to new uses, and the hardware changes. A particular piece of code that theoretically doesn’t change would still need to be tested in the first instance, which destroys this excuse somewhat.

The login code will be the same. UNTIL THE END OF TIME.

But anyone who is certain that a piece of code will not change in the future is either hopelessly naive or deluded. You don’t want to be that member of staff, do you?

Remedy: Bake flexibly in.

“The client doesn’t pay for us to test”

This is partially true, and certainly true when I heard this at work a couple of years back. The client isn’t interested in what you had for breakfast either, but they do expect your work to be of reasonable quality.

The client might pay for a product that works, that is a given, but they will only pay for features in the future that work and are a reasonable price. Without testing, code is unlikely to be maintainable (we can’t work out where that bug is coming from) and difficult to build on.

Bugs are from a mature codebase.

If an employer has quoted for work without accepting that time needs to be spent testing you would be well-advised to still test. Cutting corners is a bad business practice, and should be avoided even if you need to finish a job satisfactorily in your own time.

“This code is too small”

This seems, on the surface to make sense. My colleague created testable code with nice small classes that have a single responsibility. Within those classes, you have small methods that only do one thing, and it can be relatively simple to see what those methods should do and you seem to be testing a single thing that is so small…it kind of doesn’t feel worth it.

Yet…requirements change. Functions change. Your tiny method grew.

But when I made it, it represented perfection.

Not only that, it touched pieces of code deep within your code and might have truly difficult side-effects, and the cost in time to find the issue may well be…awful isn’t quite the word.

“This Code is wholly dependent on the API/User input”

I think my developer colleague simply didn’t want to test, and they wanted to confirm that I knew mocking exists. I can’t come up with another explanation.

UI Tests? There are so many tools and frameworks for this you wouldn’t believe. Is it that you don’t think tests are important?

No, it’s that my code is perfect.

Simulating the environment for tests is really important, and having accurate unit tests allows us to make sure that the code works as intended before anyone else sees our silly mistakes. This is irrespective of the dependencies for your code.

“Nobody Checks, Nobody Cares”

Surely people within the organization care that the software works? I didn’t feel that they did after I hear “nobody checks, nobody cares” used as a motto at work.

Hard crashes mean that the user experience isn’t all it could be, and on the hosting platform, you might see negative feedback, or the customer support division might get rather a large number of unfriendly phone calls from users.

Dealing with dissatisfied customers takes time, energy, and sapping motivation.

It tells everyone you don’t care.

The costs stack up, even if those costs aren’t immediately obvious.

Doesn’t it also make sense to have pride in your own work?

That reason you should test, no matter what your colleagues say

That’s your job. It gives you security in your code and shows that your code works.

It’s that simple.

Conclusion

Look, we all make those little excuses sometimes. The problem is that you start to make a habit of it, and often your standards slip.

That’s not a good position to be in.

Reverse it now and do your best to create the best high-quality code you can. It makes sense.