Which automated tests your product needs and what they cost

A product needs automated tests on its critical flows first — payments, sign-up, checkout, access control — not 100% code coverage. The foundation is fast tests of business logic and the API, topped by a small number of end-to-end browser tests. Such a suite adds a noticeable but worthwhile share to development time: it saves on manual checking and post-release bugs.

Here are the types of automated tests, what to cover first and how to tell whether they pay off.

Why does a product need automated tests?

Automated tests let you ship every change without fear of breaking what already works. Without them each release requires manual checking of the whole product, and over time the team grows afraid to touch old code — and development slows down.

What automated tests give you:

• bugs are found minutes after a change, not by users;
• releases become frequent and calm;
• refactoring and dependency upgrades stop being risky;
• tests document how the system should behave;
• new developers are less afraid to change someone else's code.

What types of automated tests are there?

Tests differ by level: unit tests check individual functions, integration tests check several parts working together, including the database and API, and end-to-end tests check whole scenarios through a browser or mobile app. The higher the level, the closer to a real user — but the slower and more brittle.

Type	What it checks	Speed	How many you need
Unit	Individual business logic functions and classes	Milliseconds	Many — for complex logic
Integration and API	Endpoints, database, queues, integrations	Seconds	The bulk for a web product
End-to-end (E2E)	User scenarios in the browser	Seconds to minutes	A few — critical flows only
Contract	API compatibility between services and clients	Seconds	When there are external clients or services

For a typical web product, API tests give the best value for effort: they are fast, exercise real database work and do not break when the layout changes.

Photo: Unsplash

What should you cover with tests first?

Cover first the flows where a bug costs money or trust: payments, sign-up and sign-in, checkout, data access control, calculations — prices, discounts, taxes. Then cover the areas that have broken most often in the past.

A Laravel API test that checks an important access rule:

public function test_user_cannot_see_someone_elses_order(): void
{
    $owner = User::factory()->create();
    $stranger = User::factory()->create();
    $order = Order::factory()->for($owner)->create();

    $this->actingAs($stranger)
        ->getJson("/api/orders/{$order->id}")
        ->assertNotFound();
}

And an end-to-end test of a key flow in the browser with Playwright:

test('customer places an order', async ({ page }) => {
  await page.goto('/catalog/shoes')
  await page.getByRole('button', { name: 'Add to cart' }).first().click()
  await page.getByRole('link', { name: 'Cart' }).click()
  await page.getByRole('button', { name: 'Checkout' }).click()
  await expect(page.getByText('Order placed')).toBeVisible()
})

What not to do

• chase a coverage percentage — a hundred getter tests will not protect payments;
• write hundreds of end-to-end tests — they are slow and break with layout changes;
• test implementation instead of behaviour — such tests get in the way of refactoring.

How much do automated tests cost?

Automated tests cost developer time: in our experience, writing them adds 15–30% to feature development — our own benchmark, depending on logic complexity and reliability requirements. They pay off through less manual checking, fewer production bugs and cheaper changes later.

How to assess the payback:

1. Count how many hours manual regression checks take before each release.
2. Estimate the cost of production bugs: fixes, lost orders, support tickets.
3. Compare this with the cost of writing and maintaining tests.
4. Remember that without tests the cost of each change grows as the product grows.

For a product developed for more than a few months, tests almost always pay off. For a throwaway prototype, they do not.

How do you build automated tests into the process?

Build tests into the process through CI: they run on every change, and a change cannot be merged until they pass. A test for a fixed bug is written together with the fix, so the bug does not come back.

Rules that work:

• tests run automatically on every pull request;
• new business logic is accepted in review only with tests — see code review best practices;
• every fixed bug gets a test that reproduces it;
• flaky tests are fixed immediately, or the team stops trusting them;
• test data is created with factories, not copied from production.

Tests running regularly also lower post-launch support costs — we covered this in website and app support cost.

In short

• Automated tests let you ship changes without fear of breaking what works.
• For a web product the bulk should be API and business logic tests, with few end-to-end tests.
• Cover payments, sign-up, orders, access control and calculations first.
• Tests add a noticeable share of development time but pay off in any product that lives more than a few months.
• Run tests in CI on every change and add a test for every fixed bug.