Automated tests: what are they really for?

An automated test is a small program that checks that part of your application does what it should, and that runs again by itself after every change. It does not make the product perfect: it warns you when a change breaks something that used to work.

The analogy: the pre-flight checklist

A pilot does not trust memory: they run through the same list before every flight. Not out of carelessness, but because it is reliable and quick, and forgetting something costs dearly.

Automated tests are that list, run on your application by a machine, in seconds, as often as you like.

What a test checks

Each test sets up a situation, performs an action, and checks the result. For example: "a customer with a valid promo code sees the total go down", or "a visitor who is not logged in cannot open the billing page". If the result changes, the test fails and tells you before your users find out.

There are several levels:

• unit tests check one small, isolated rule, such as a discount calculation;
• integration tests check that several pieces work together, such as the application and its database;
• end-to-end tests walk through a real journey, from sign-up to payment, the way a visitor would.

What they are for, concretely

• Daring to change things. Without tests, every change raises the fear of having broken something elsewhere. With them, you move more calmly.
• Finding the failure right away, while it is still small and the change that caused it is fresh.
• Documenting what the application must do. A test is a checkable sentence: "this is what should happen".
• Taking over a project: existing tests say what matters to the product, and let you change it without guessing.

What they do not do

• They do not prove there are no bugs: they only check what someone thought to test.
• They do not replace a human eye on the experience, the design or the relevance of the product.
• They have a cost: they must be written and maintained. Too many tests on details that keep changing become a burden.

So the right question is not "test everything" but "what would be serious to break?": payments, access rights, important calculations, key journeys. That is where tests pay off most.

And in a project generated by AI?

Code produced quickly by an AI tool often runs with no tests at all. That works as long as nothing is touched, and becomes fragile at the first change. See Lovable, Bolt, Cursor: What Changes When AI Writes Code. To understand where some of the bugs tests help catch come from, you can read Race condition: two tickets for one seat.

Key takeaway

An automated test is a checklist a machine runs after every change: it does not guarantee there are no bugs, but it warns you when you break what used to work.

And for your product?

If you are taking over a project with no tests, there is rarely a need to cover everything: you start by protecting the few journeys that really matter, then extend little by little. It is a common part of a project takeover, and it lets you evolve the product with less fear afterwards. We can talk it through in a 30-minute conversation.