When we talk about software development, sooner or later someone starts a discussion about tests. In our world, tests are considered as something helpful and crucial to our work. However, sometimes we need to face with people who have a different opinion about it. Moreover, it’s hard to find a proper argument, especially for a person who pays you and who wants to utilize your time effectively.

How can you convince your boss to let you write tests? Should you even ask for permission?

Convince yourself first

You already test the app manually

You can compile the application, run it and check if your changes work by clicking through the app. Your feature may not work after the first trial, so you need to fix the code and go through the same process – compiling, running and checking. You already perform manual tests.

This testing process gives you feedback about your work. If the solution works and matches the requirements, you can go ahead. Otherwise, you need to go back to the development phase.

It’s unreliable to write the code and then commit it without testing if it works. Even simple manual tests are vital to confirm that your change is working correctly.

You’re responsible for writing good-quality software

Your job is to deliver working, good-quality software. Some people say about good-enough level, but it still software that is reliable, easy to maintain and develop. When the company hires you, people expect that you’ll do your best to deliver software, not worse that it currently is.

Tests are necessary to write reliable software

I don’t know any good piece of software which was writing without tests. As long as the application is small and simple, finding bugs and problems isn’t a big deal. But the more complex app, the more time you have to spend testing it manually. Ultimately, it’s almost impossible to check every affected use-case in a reasonable amount of time, so developers test only the most crucial part of the app. It should no longer be considered reliable – nobody can prove it.

Writing tests is a part of the development process

Tests, especially unit and integration tests, support you with day-to-day development. You can write them before the code (according to TDD), but you can also create them after the production code. Anyway, they are still part of the development process. You may don’t know which strategy would be better in the specific case.

You should keep the development and testing¹ parts under the same sign – software development. Mark features as done, but only if you finished both: production code and tests.

How to convince your boss to let you write tests?

Simple answer: do not do this.

If you convinced yourself first, you should know that tests are for you. Your job is to deliver working, good-quality software. How could you do that without testing if the code you wrote works correctly? Do you provide untested solutions? I know you don’t.

What would say your boss, if you would ask him if the feature you work on should be tested? Would he be surprised? For sure, he pays you to deliver working features. He expects the outcome.

People expect that they get a good quality product. In the restaurant, the chief wouldn’t ask you if the dish you’ve ordered should be tasty or not.

Writing tests should be your decision

If it doesn’t convince you, ask yourself, who will be responsible if something goes wrong? The code is the common good, so the whole team should take responsibility for each failure and mistake. Not your boss, who doesn’t let you write tests.

Tests are for you. They should help you with your work. Saying “you shouldn’t write tests, it’s a waste of time” have roughly the same meaning as “you shouldn’t use design patterns, it’s a waste of time”.

Having tests is like having contracts for requirements to the developed feature. Having automated tests is like having a partner to check if the code meets all requirements.

Remember, you already test your software, anyway. You can also automate this process. Is it in anyone business to discourage you not to test software you produce?

Don’t ask for permission to write good-quality software. It’s your job.

Change the way you communicate

We all know that tests should be an integral part of any feature we produce, any new class we write and any other development endeavour. Tests are part of our craft, not extras to it. However, this is not consistent with the way how we use to communicate the testing part to the outside world. Have you heard this?

“Yes, this feature is ready, but I have to write some tests for it.”

“It’s done, yet I need to write unit tests.”

“Everything is working, but I need a couple of hours to write automated tests.”

Since we agreed that tests are an integral part of the development process, why we talk about them as if they were a separate part? How could something be done if a part of the whole is missing?

By talking that the feature is done without tests, you communicate that development and tests are two separate parts². Moreover, if the first part could be finished and delivered without touching the latter, it shows that tests are redundant.

It’s not about hiding the fact you’re writing tests. Your goal should be not to deceive the management but to show the actual situation honestly.

Change the way you talk about tests. Treat them as a part of the development process.

Featured photo by Juan Rumimpunu on Unsplash.