لماذا نختبر آلياً

Written Explanation

Checking by hand

Take the Account class from the exceptions module (it has deposit, withdraw, and getBalance). A manual check looks like this:

public class ManualCheck {
    public static void main(String[] args) {
        Account a = new Account("Sam", 100);
        a.deposit(50);
        System.out.println("Balance: " + a.getBalance());
    }
}

Output:

Balance: 150.0

You look at 150.0, think "that is right", and move on. Notice what this check depends on: you. You must remember to run it, remember what the right answer is, read the output carefully, and do all of that again after every change. Checking by hand has three weaknesses:

• It is slow: for fifty behaviors you would read fifty lines of output every time.
• It is easy to forget: nobody re-checks the deposit after editing withdraw.
• It is inconsistent: today you check three things, tomorrow five, and neither of you wrote down which.

An automated test

An automated test is a small program that runs a piece of your code, compares the result with the answer you expect, and reports pass or fail by itself. Here is the smallest version, without any library:

public class HandCheck {
    public static void main(String[] args) {
        Account a = new Account("Sam", 100);
        a.deposit(50);
        if (a.getBalance() != 150) {
            throw new AssertionError("expected 150 but was " + a.getBalance());
        }
        System.out.println("deposit check passed");
    }
}

AssertionError is a standard JDK error type meant for "a check that should hold did not". The program now contains the expected answer (150) and the decision (compare). Nobody has to read anything: when the balance is wrong, the program stops with an error and a message. When it is right, it prints one calm line.

Three things changed. The expected answer is written down once, in code. The comparison is done by the computer, so it is identical every time. And you can run it as often as you like, in a fraction of a second.

Regressions

A regression is a feature that worked and broke after a change. Regressions are the most common bug in a growing codebase, because the change that breaks the feature is usually in a different place from the feature.

Imagine a teammate tidies up deposit and accidentally writes balance = amount; instead of balance += amount;. Here is what each kind of check says:

Manual check:      Balance: 50.0
Automated check:   Exception in thread "main" java.lang.AssertionError: expected 150 but was 50.0
                       at HandCheck.main(HandCheck.java:6)

The manual check still prints a number, and 50.0 looks as plausible as 150.0 if you are not paying attention. The automated check cannot be fooled by plausibility, because it knows the answer.

Why teams write tests

The last point is the one experienced engineers value most. Martin Fowler describes how teams without good tests can become afraid to touch old code, even to fix bugs, because any change might break something else. With tests, the code can be kept clean.

Tests are living documentation because, unlike a comment, a test that no longer matches the code fails. A comment can quietly become false. A test cannot.

What tests cannot do

Be honest about limits. A test only checks what you thought to check: passing tests do not prove the program has no bugs. Tests also take time to write and to keep up to date. And a badly written test (one that checks nothing, or checks the wrong thing) gives false comfort, which is worse than no test. The rest of this module is about writing tests that are worth their cost.

Where this fits in a workflow

A common team habit: when a bug is reported, first write a test that reproduces it (it fails), then fix the code (the test passes). The bug can never return unnoticed, because the test stays. This is the idea behind the planned mistake you will meet in the last lesson of the module.