Introduction to Automated Testing

In the previous chapters, we’ve looked at both interactive and automated testing. In general, both play an important role in developing code confidence and, therefore, development speed.

• Interactive testing helps us become confident in our new code.

• Automated testing helps us maintain confidence in our old code. When changes are made to one part of the application, we want to be confident that the other parts won’t break. Automated testing is ideal for this.

Automated testing

Automated tests work best at the most granular and global levels. We’ve looked at the granular end of the tests: unit tests.

• Unit tests should run quickly and be checked routinely, such as after every code commit.

• Integration tests, which check an entire use case, generally take longer. They don’t belong in our development process inner loop. Typically, integration tests are run less often, such as when pushing a development version into production.

Test automation can be simple or complicated, but it tends to be more complicated than needed. Issues arise because we’re often testing on the development machine and hoping it will then work on the production machine. Operating system and configuration differences can cause discrepancies: the tests pass on the machine, but it becomes buggy when we put it into production. These sorts of issues are challenging to debug since the feedback loop is lengthened by pushing each fix attempt to the production server to check it.

Use of virtual machine

Writing good code is easier when we have dev-prod parity, which means that our development and production servers are identical. One way to get there is to use a virtual machine or a container (for example, Docker).