أولى اختبارات JUnit 5

Written Explanation

Adding JUnit to the project

Until the build-tool module, your project has no build tool, so the IDE adds the library for you. In IntelliJ IDEA, the usual path is: write a test class, and when the IDE notices that the testing library is missing it offers to add it (look for a suggestion on the @Test annotation, often reachable with Alt+Enter). Alternatively, open the Project Structure dialog, go to Libraries, and add a library from Maven by name. JetBrains documents both routes; menu names and shortcuts may differ in your version or in another IDE, so follow your tool's own help if they do not match.

Choose the JUnit 5 library (its Maven coordinates start with org.junit.jupiter). Be careful not to pick an older "JUnit 4" option: the annotations live in a different package and some names differ. In a later module a build tool (Maven) will manage this for you, and your projects will be migrated.

A typical project layout keeps the code and its tests in separate folders, with the test class named after the class it tests:

src/Account.java
test/AccountTest.java

If your IDE offers a "Tests" source root, use it. The two files are compiled together, so the test can use Account directly.

A test class

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class CalculatorTest {
    @Test
    void addsTwoNumbers() {
        assertEquals(5, new Calculator().add(2, 3));
    }
}

The pieces:

• @Test (from org.junit.jupiter.api) marks a method as a test. JUnit finds every @Test method and runs it.
• A test method returns void and takes no parameters. According to the JUnit user guide, test methods and classes can have any access level except private, and the guide recommends leaving out public unless you have a reason. That is why the examples here have no public.
• import static org.junit.jupiter.api.Assertions.*; lets you write assertEquals(...) instead of Assertions.assertEquals(...). The static import is the same feature as Math.max becoming max.
• JUnit creates a new instance of the test class for each test method by default, which helps keep tests independent. Do not rely on fields to pass data from one test to another.

JUnit decides the order in which test methods run, and it is not necessarily the order you wrote them in. In our run, maxOfEqualNumbersIsThatNumber ran before maxReturnsLarger even though it was written after. Your tests must pass in any order, which lesson 2 already required.

The assertions you need first

All of these are static methods of org.junit.jupiter.api.Assertions.

When an assertion fails, it throws an AssertionFailedError; JUnit catches it and marks that test as failed, then carries on with the other tests.

Prefer assertEquals over assertTrue(a == b): when it fails it prints both values, while assertTrue can only say "expected true". Use assertTrue and assertFalse for conditions that really are yes/no, such as account.isActive(). For objects, assertEquals uses equals, so it works for String and for your own classes once they implement equals correctly (the equals/hashCode lesson).

Expected first, actual second

The signature is assertEquals(expected, actual); the JUnit Javadoc names the first two parameters expected and actual in that order. The failure message prints them under those labels, so if you swap the arguments, the message lies to you. Example 3 shows it.

Comparing doubles

Account stores a double. Decimal fractions such as 0.1 are stored approximately in binary, so arithmetic can give a result that differs in the last digits. For double, give a tolerance:

assertEquals(0.3, 0.1 + 0.2, 0.0001);

The third argument is the delta: the largest difference you accept. Whole numbers like 150.0 are exactly representable, so the plain two-argument form is fine for them, but a delta is a safe habit for money-like values in these early examples. (Real systems usually avoid double for money; that is a design topic for later.)

Running tests

In IntelliJ IDEA, a run icon appears in the gutter next to the class name and next to each test method. Clicking the icon next to a method runs that one test; the icon next to the class runs all its tests. Results appear in a Run window: a green mark for each passed test and a red mark for each failure. Other IDEs have similar icons or a "Run test" command. Green everywhere means every test passed; any red means something needs attention, which lesson 6 covers.