In this article, we’ll explore the benefits of writing automated tests from a developer’s perspective. Not only will this be useful for developers who may not yet be convinced of the value of automated testing, but it will also provide insight for product owners looking to determine if they want to incorporate this practice into their applications.

Testing leads to failure, and failure leads to understanding. — Burt Rutan

Before we delve into the benefits of automated testing, it’s important to establish when it is and is not appropriate to write tests. While automated testing can be a valuable tool, it may not be necessary or practical for every situation. For example, it may not be necessary to write full automated tests for a simple family photo album WordPress website.

There are mainly three factors that should determine if tests are beneficial:

• Applications with a high level of complexity.

• Applications that have a crucial role and cannot fail.

• Applications with large teams working on them.

The more you have of these 3 factors, the wiser creating tests would be. Don’t worry, your WordPress website probably has none of these.

Terminology

Code exists out of multiple collaborating parts. In most languages, those parts are called objects. I’ll stick with that in this article.

Testing coverage. This is the percentage of code that is tested by automated tests.

What is an automated test?

If you’re already familiar with automated tests, feel free to skip this section.

In software development, each object has a specific responsibility and serves a particular purpose. For example, let’s say we have an object that is designed to determine if a number can be evenly divided by 2. One way to ensure that this object is functioning correctly is to create an automated test that “asks” it questions and verifies the answers. This way, we can have confidence that the object is solving the problem it was designed to solve and performing as expected.

• Is 0 dividable into 2? Expecting the answer no.

• Is 1 dividable into 2? Expecting the answer no.

• Is 2 dividable into 2? Expecting the answer yes.

• Is 3 dividable into 2? Expecting the answer no.

Applications can often consist of thousands of objects, and automated testing can help ensure that these objects are all functioning as intended.

There are two types of automated tests. Unit tests, which test a single object, and feature tests, which test multiple objects together. Both types of tests have their own advantages and disadvantages, and which one is most appropriate depends on what needs to be tested. Most projects have both.

With this in mind, let me share the main reasons why I prefer to use automated tests.

Test results of a test that validates when a shop cart is allowed to checkout.

Did I break something?

A large application has lots of objects, and all these objects interact with each other and are re-used by each other lots of times. When a developer is updating an object, it’s hard and sometimes impossible to comprehend all the places and reasons why and where that object is used.

So when a developer changes the object for some new feature, he/she tries to also keep existing features working. But the bigger the system, the harder this is to comprehend.

If each developer that changes something also provides new, and updates existing, tests for that change, all requirements for that object can be validated within a matter of seconds.

Test failing because a change introduced a bug

Manually takes up more time

Imagine a shop card in a webshop where a developer needs to change the way discounts are calculated. When done, the developer has only one way of determining if all scenarios still work. He/she needs to fill up the shop card with all the different types of products and discounts that the system supports. That’s a lot, and within that process, you hope the developer doesn’t make a mistake validating the total price at the bottom. After that, the developer needs to repeat that on the order detail page, the invoice, and probably more locations. This is time-consuming.

If there are tests present for all these situations, the developer can simply run and validate them all within 1 minute.

It’s documentation

In most cases, if a system is documented, it means someone has written a document with a set of requirements at the beginning of the project which after the first period never gets read any more. Documentation is always (or 99.9% of the time) outdated, and can have multiple interpretations.

Good tests are not unreadable abstract pieces of machine code. They have names and can be read as little stories. They can act as documentation, and documentation in form of tests cannot be skipped because of deadlines or simple laziness.

Using tests as documentation for developers / by developers

Tests force you to think

Ever heard of rubber duck programming? This is a practice developers have when they cannot seem to find a solution to something or find a bug. They put a yellow rubber duck on their desk and start to explain the problem to the duck. Forcing them to take a helicopter view of the problem and re-evaluating the code. This thinking process tends to reveal the issue they are struggling with.

You can always emplane it to the duck

When writing tests, developers are forced to think the same way as with rubber duck explanation sessions. Resulting in a broader understanding of the process and discovering aspects nobody has thought of before. This can sometimes increase the scope of the requirement, but it’s better to have this within your development process instead of after when the new feature is live.

New developer

Last, but still important… When your gigantic complex application is running in production for a long time, let’s say 3 or 4 years. 2 of your lead developers (those who know all the ins and outs of the system) decide to leave and you are lucky enough to find replacements in time.

The chances of them introducing 10 new bugs for each feature they add or update are gigantic. Experienced developers will introduce a bit fewer bugs, but they will still add them. They are too unfamiliar with your application. For them, it’s impossible to comprehend 100% of the consequences of some changes they need to do.

Having good testing coverage can significantly reduce the risk of introducing bugs when updating objects in a large application. Automated tests can inform developers of any issues that may arise as a result of their changes, allowing them to fix these problems before the update is released. This can provide peace of mind for both developers and product owners, as it ensures that the application is stable and reliable after each update.

Wrap it up

I hope this article has given you extra knowledge about the benefits of having automated tests so you are able to make better decisions about this if needed.

Each of the points I discussed in this article is a result of the experiences I’ve had with testing the projects I have worked on. This is no why-you-should-TDD article (I almost never write my tests upfront, most times somewhere in the middle of the process). And I’m also not promising a bug-free project.

It’s practical knowledge you can use to improve the process of developing complex applications.

Are you a Laravel developer and new to testing? Here are some good resources to start with:

• Laravel Testing For Beginners: PHPUnit, Pest, TDD

• Laracasts Category: Testing