تشريح حالة اختبار

Written Explanation

What a test case contains

Every test case answers one question: when I do this, with this, do I get that? It has three parts:

The expected result is the part beginners skip. Without it you have a program that runs, not a test.

Arrange, Act, Assert

The standard layout of a test body has three steps, in this order:

1. Arrange: build the objects and values the test needs.
2. Act: call the code you are testing (usually one call).
3. Assert: check that the result is what you expected.

static void depositIncreasesBalance() {
    // Arrange
    Account account = new Account("Sam", 100);
    // Act
    account.deposit(50);
    // Assert
    Check.equal(150, account.getBalance());
}

Here Check.equal(expected, actual) is the small helper from lesson 1 (it throws AssertionError when the two numbers differ). Keep the three parts visually separate, with blank lines or comments. When a test fails, you can then tell at once whether the setup, the call, or the check is the part to look at. Arrange, Act, Assert is usually shortened to AAA.

A useful rule: if you find yourself writing a second Act after the Assert, you are probably testing two behaviors and should split the test.

One behavior per test

A good test checks one behavior. "Deposit increases the balance" is one behavior. "Deposit increases the balance, and withdraw decreases it, and a negative deposit is rejected" is three, and if the test fails, the failure does not tell you which one broke. One behavior does not mean exactly one assert line: checking that a method returns the right value and left the object in the right state can belong to the same behavior. It means one reason to fail.

Naming a test

When a test fails, the name is the first thing you read. Name it after the behavior, not after the method or a number:

A good name reads as a sentence about the code: "deposit increases balance". If you cannot name the test without using "and", it probably checks too much.

Independent tests

Tests must be independent: each one must pass or fail on its own, in any order, and running one alone must give the same result as running it with the others. The usual way to break this is shared state: two tests use the same object, so the first test's changes leak into the second.

The simplest cure is the one in the AAA example: every test arranges its own objects. JUnit helps by creating a fresh instance of the test class for every test method, but that protects only instance fields; anything static is still shared, and so is anything stored outside the program, such as a file or a database. Treat each test as if it were the only one on Earth.

A related rule: a test should not need another test to have run first, and it should not leave anything behind that another test depends on. If your tests only pass in one order, they are chained together, and a failure in the first will show up as a confusing failure in the second.

A test without an assertion

Consider this:

static void t() {
    new Account("Sam", 100).deposit(5);
}

It has input and action but no expected result. It can fail only if the code throws an exception. If deposit silently does the wrong thing, this "test" still passes. It gives you a green result and no information. Always ask of a test: what would make this fail? If the answer is "nothing", it is not a test.