Software is built to solve problems, not to pass tests • vito tardia

The ultimate goal of any software should be to solve problems. Our problems. Our customers’ problems.

The goal of any software shouldn’t be to pass tests. Neither to get a bunch of shining badges from code coverage and code quality tools. These are tools, a mean to an end, not the end goal. Their goal is to help us developers building better programs to solve other problems.

But tests and code coverage are nonetheless important to keep your software “healthy” and maintainable.

Sometimes though, you end up skipping these steps because you need to ship your software fast for some reason. I don't always recommend that, but I'm not judging. Been there, done that.

Once you have your software running you realise that adding tests could be a good idea. It’s a great idea, indeed. But chances are that you have built a large codebase and the thought of writing all these tests seems overwhelming. You risk seeing it as more code to maintain.

Here are my 2 cents for writing test code without going nuts:

1. Keep calm and don’t panic

It’s a tool, remember? You are in control, and you decide how to use it in your project.

2. Start writing tests for new features

Building tests for current code can be complicated, so start with an easy win and add tests for new code. It feels like you’re starting from scratch. It will be easier to pay attention to subtle details like objects dependencies.

If your codebase is PHP, there is a nice tool called PHP Testability. It’s a tool analyses your code and generates a report of testability issues.

3. Use the 80/20 principle

A shining 90-100% green badge can be tempting, but normally 20% of your code handles 80% of your features. You need to identify this code and start building tests around it. Don’t refactor the code yet! The goal is to test current code, refactor comes later.

4. Add more tests and refactor

With these core tests in place, you can now decide to dedicate some hours a week to write the remaining tests. And think about refactoring.

5. Refactor with a plan

You should not try to rewrite the entire codebase every month. You have a product that it’s supposed to be used by your customers, remember?

Writing tests is a good occasion to spot which elements of your code will benefit the most from a refactoring. Make a list in order of priority and start working on it, one item at a time.

Sometimes a good occasion for refactoring a piece of code comes out while fixing a bug or adding a new feature. Go for it. And don’t forget to update your tests.

6. Practice code review

If you work in a team, code review is an awesome tool. I myself sometimes tend to over engineer tests and features, this is where code review comes handy. Another teammate could find better ways to code a certain function. Or she spot shortcomings in your code design, like useless database tables.

Enjoy those badges and have fun

With a system in place, you can now choose your favourite QA tools and look at your badges’ colours turn from red, to yellow and green as your code quality improves.

Depending on your favourite language, you may also be interested in reading:

Happy Testing!