Automated tests are slower than what exactly?

One of the myths that exist in the world of software development is beyond question the fact that writing automated tests tends to slow down our productivity. But does it really? While we believe to code faster without tests, this is in fact a mere illusion. Unfortunately, there are several companies who fail to see the real added-value of software quality.

Let’s examine this myth in greater depth

I would like to ask you the question: what is slow exactly in writing automated tests? Slower than writing code without testing it? A developer must test his code at least once, even if it’s written manually.

How do you conduct your manual tests?

You make a list of possible scenarios or test cases. You integrate your methods into your software, start the program, and note down the results. This might seem fast at first sight, but you might have started a server, waited until the software opened, and then looked for the results of your test. If you find a bug, you will have to redo this heavy procedure once it’s fixed.

And with automated tests?

You make the same list of scenarios representing your test cases. You interpret your scenarios into code only once. Next, you write your code and immediately see the results, in a few seconds. Why do you need to start your software only to assert that your method works? Once you find a bug, all you have to do is to change your production code and see your new results immediately. You do not need to repeat the same testing process provided that it’s already written! The best thing in the end is that your tests will still exist for several months. Therefore in the future you can always be certain that your methods are working along with a supporting evidence (yes, every tests have passed successfully!). Furthermore, these tests are an excellent reference for developers to understand your methods, since all these are actual examples of use.

Validate the regression, an added-value

Ensuring the proper functionality of your software is essential. Ensuring that it would still work even after a new feature is added is just as much an essential. During a modification, redoing the same old same tests is a huge waste of time. In fact, validating the regression is one of the most important added-values in automated tests. These tests make sure that your software works at all times without any additional effort required.

All of this is indeed interesting, but it’s not for us

In fact, it certainly applies to every company that integrates software development. If the world’s leaders such as Google, Microsoft, Facebook and others, manage to automate their tests, then you can definitively automate yours. If you have any difficulty testing your software, that is simply because your architecture is not designed to be testable. Michael Feathers proposes a very interesting approach to this problem in his book “Working Effectively with Legacy Code”. He provides a clear-cut explanation on how to move from a “legacy” system on to a testable and easy-to-maintain system.

Thus, I would like to conclude by sharing with you this Félix-Antoine Bourbonnais‘s excellent quotation:

You are not paid to do tests? Neither are you paid to create bugs!


Share this post

Comment (0)

Leave a comment