3 Reasons You Should Start Testing Today

Preface

This series has been heavily influenced by Robert Martin ’s clean code series which I extremely recommend for every developer.

Software testing has always been a controversial topic. Some say it is a waste of time while others say that it is the only sane way to develop and extend large software systems.

Personally, I belong to the latter camp. I believe testing is one of the greatest practices one could apply to produce high quality systems while keeping them maintainable for the long run.

There are 3 main reasons that make testing such an essential tool in software development:

1. Avoid Unintended Changes

Let’s take an example of a system with two modules: F eatureX and C ommon . Another developer works on adding FeatureY and changes methods in C ommon module to support the new requirements.

How can they know their changes to C ommon affected F eatureX ?

What if the system doesn’t have a single feature and a single common module, but hundreds of feature modules and dozens of common modules, with a mixture of dependencies?

How could one possibly make changes to the system without having a safety net?

I know only one good answer to this question: Automatic test suits.

As a developer, writing tests for my code is my way to ensure that future developers that change it won’t break existing behavior without having at least one test fail to warn them. It is my way to alert them and get their attention to changes they may have caused to other parts of the system. Tests are my tool to protect my code from unintended behavior changes.

Failing tests make the developer confront with important questions: why did it fail? what does this failure mean? is it how I want things to behave or have I broken existing behavior? They will probably use their more experienced peers to make sure they haven’t.

If the changes are desired, they now have to adjust the tests to reflect the new system behavior. This forms a very solid and safe development cycle.

When code I wrote is broken by the work of another developer and none of the tests have failed — I see it is a personal failure of mine since this is my responsibility to make sure not only that my code works today but also that it survives the inevitable system evolution.

2. Fast Development Cycles

You’re adding a new feature to your API server, you think you’re done and you want to make sure it works as expected. You enter into the REPL and run some commands: you create some fake data and use some of the new modules you wrote just to see they work well. Then you run the web server and run curl commands from bash to examine the output. You also open a connection to the database to see changes has been persisted correctly.

You just invested 20 minutes to manually test your feature. The next time you make changes to it, you’ll have to spend the exact same 20 minutes to make sure it didn’t break.

I claim automatic tests are a far better investment of time: They provide faster, incremental feedback and they serve you throughout all of your future changes to the system. I mean, you have to invest some time in testing, either manual or automatic, so why not invest it in a more efficient and productive way?

You can use TDD (Test Driven Development) or even create the tests after the actual code — it doesn’t really matter. Having the tests during development allows you to make sure your code works in small steps, without running the whole system, be it a web server, a background job processing or a mobile application. In a matter of milliseconds, you know whether your code does what it should or not.

The next time you or one of your teammates make changes to the system, they won’t have to come up with a testing procedure — they already have one and it is ready to run.

Deployments to the dev or staging environment become more of a final validation rather than an initial test for the code.

3. Document System Behavior and Indirect Considerations

You’re working on a multi-threaded system and you set a constant value in the code NUM_OF_THREADS=4 . You leave a comment before the declaration:

But the file is already full of comments (actually there are more comment lines than actual code), the comments themselves are displayed with a weak, faded color and the tired developer overlooks your precious reminder. They change the value and deploy to production. You’re starting to get alerts all over the place.

Comments have a few inherent problems:

1. They rot since changing the code does not enforce the developer to change them as well. When that happens, comments become deceiving and misleading since they don’t reflect the system behavior anymore.

2. They clutter the code and in some cases, become more dominant in our codebase than our actual code. They become so widespread that we train our minds to ignore them to be able to focus the code itself.

3. They are prone to human errors because they rely developers to actively pay attention to them.

Tests, on the other hand, are the exact opposite:

1. They cannot rot because when we change the code in a way that makes them untrue, the CI fails the change and forces the developer to either correct the test or the code.

2. They are completely separate from our actual source code so they don’t clutter at all.

3. They integrate into automatic procedures such as CI and when enforced correctly does not rely on human awareness at all — changes cannot be applied until all tests pass.

That’s why I believe tests are the ultimate documentation for your system behavior and for indirect considerations needed to be taken into account when changing it.

The Fear of Change

The outcome of having a well formed test suit is gaining confidence in your ability to change the system without having the fear of breaking it.

• Refactoring to improve code quality becomes a fun exercise rather than a nerve-wracking episode.
• Changes to existing behavior are done with full awareness to consequences on other parts of the system rather than fearing the unknown.
• Features arrive to staging and production faster, with fewer bugs and much less manual QA.

Even though testing does take its toll when it comes to development time, your developers will end up happier and more productive working on a well-tested system.

In the next post in the series, we’ll take a look at a few guidelines to build an efficient, time and cost effective, test suit for your system.

Advertisements