Why Automated Tests

Confidence to change code

An automated test is code that runs your code and checks the result. Its real value is confidence: you can refactor, upgrade libraries or accept a teammate's change knowing that important behaviour still works, and you find mistakes in seconds instead of in production. A unit test checks a small piece of behaviour (usually a class or a few collaborating classes) in isolation, quickly and deterministically, with no network, real database or clock. Integration tests check that pieces work together, such as a repository against a real database or a controller with the web layer. End-to-end tests drive the whole system. The test pyramid recommends many fast unit tests, fewer integration tests and very few end-to-end tests, because lower tests are faster and pinpoint failures better. Good tests are fast, isolated (no shared state between tests), repeatable (same result every run), self-checking (pass or fail automatically) and timely (written with the code), often summarised as FIRST. In Java, JUnit runs tests and Mockito replaces collaborators with test doubles.

The test pyramid

Many fast unit tests at the base, fewer integration tests, very few slow end-to-end tests.

What a unit test protects

A tiny rule and the test that guards it.

public final class ShippingCalculator {
    public long feePaise(long orderTotalPaise, boolean express) {
        if (orderTotalPaise >= 100_000) return 0;          // free above Rs 1000
        return express ? 9_900 : 4_900;
    }
}

class ShippingCalculatorTest {
    private final ShippingCalculator calc = new ShippingCalculator();

    @Test
    void freeShippingAtOrAboveThreshold() {
        assertEquals(0, calc.feePaise(100_000, true));
    }

    @Test
    void expressCostsMoreBelowThreshold() {
        assertEquals(9_900, calc.feePaise(99_999, true));
        assertEquals(4_900, calc.feePaise(99_999, false));
    }
}

Test behaviour, not lines

Aim tests at the rules your code promises (free shipping at Rs 1000) rather than at how it is implemented. Behaviour-focused tests survive refactoring; implementation-focused tests break whenever the code is tidied.

Quick check: Which property is part of the FIRST principles for good unit tests?

• Repeatable
• Flaky
• Remote
• Sequential only