Table of Contents
Test automation
Test automation is the practice of running tests programmatically rather than manually. Instead of a person clicking through an application to verify that features work, a program does it. The tests run on every change, give a pass/fail result within minutes, and never forget to check something.
The test pyramid
A common mental model is the test pyramid:
[E2E tests] few, slow, high confidence
[integration tests] moderate count and speed
[unit tests] many, fast, cheap
Unit tests sit at the base: hundreds or thousands of them, each testing one function in isolation, running in milliseconds. They are cheap to write and fast to run.
Integration tests verify that components work together: a function plus the database it reads from, a service plus the API it calls. They are slower (involve real I/O) and harder to isolate, but they catch interface mismatches that unit tests cannot.
End-to-end (E2E) tests exercise the full system from the user's perspective: a browser automation script that loads a page, fills in a form, and checks the result. They are slow, brittle, and expensive to maintain, but they give the highest confidence that the product actually works from the outside.
Why automate
Manual testing does not scale with the size of the codebase. A codebase with a thousand features cannot be re-tested manually on every change. Automated tests make it possible to verify the entire known behaviour of the system in minutes, which is what makes CI/CD pipelines useful.
The secondary benefit is that automated tests are a precise record of the expected behaviour. A new developer can run the suite and immediately know what the system is supposed to do.
Test coverage
Code coverage measures what fraction of production code is executed by the test suite. A coverage tool instruments the build and reports which lines or branches were hit. 80% line coverage is a common baseline, though coverage alone is not a useful goal — a test that executes a line without asserting on its output does not verify anything. Coverage is most useful as a tool for finding untested code, not as a target metric.
