The goals of automated testing

Testing is more than creating a safety net. Let’s talk about its multiple facets.

Luís Soares
CodeX
Published in
7 min readDec 3, 2020

--

In an agile mindset, the team is responsible for the delivered software. In this scenario, QA is ensured by the whole team. Automation is a core tenet of DevOps culture, meaning developers should write automated tests. Manually testing everything does not scale up and is incompatible with continuous delivery. QA-specialized people should be doing other types of work like exploratory testing, usability testing, acceptance testing, etc.

Automating everything — from build to tests, deployment and infrastructure — is your only way forward. The Practical Test Pyramid

According to the xUnit Test Patterns book, there are multiple goals of test automation:

Goals of test automation according to xUnit Test Patterns

Tests as specification

Tests are like the floor plan of a house (although in software development, we can iterate); they define the system’s behavior, or in other words, what is expected: as soon as tests go green, they lock the implementation to that contract (design by contract). That’s how precious and precise a test is, given that it enforces a specific implementation (the how) to faithfully respect that spec (the what).

I know this sounds ridiculous; but consider. If somehow all your production code got deleted, but you had a backup of your tests, then you’d be able to recreate the production system with a little work. Test First

Tests are a self-verifying executable specification since you can run them, and they will automatically report the outcome. In RSpec and BDD, tests are called specs for that reason. Each test should execute only one action on the test subject. Also, that action may have multiple side effects, but each test should assert only one.

--

--

Luís Soares
CodeX
Writer for

I write about automated testing, Lean, TDD, CI/CD, trunk-based dev., user-centric dev, DDD, coding good practices,