JUnit Reference - Week 5 Reference

Setup checklist

JUnit 6 dependency in pom.xml — if IntelliJ shows the Fix button next to a missing import, click it to add it automatically.
Test class lives in src/test/java/... (not src/main/java).
Test class mirrors the package of the class under test — e.g. com.yearup.hotel.Room in src/main/java → com.yearup.hotel.RoomTest in src/test/java.
Test class name is the class under test + Test suffix: RoomTest, CalculatorTest, InventoryTest.
Each test method is annotated with @Test and is public void.

Imports — every test class needs these

Import	What it gives you
import org.junit.jupiter.api.Test;	The `@Test` annotation that marks a method as a test.
import static org.junit.jupiter.api.Assertions.*;	All assertion methods (`assertEquals`, `assertTrue`, etc.) without the `Assertions.` prefix.

The static import matters. Without it you'd have to write Assertions.assertEquals(...) on every line. With it, you write just assertEquals(...).

AAA Template — copy this and rename

@Test
public void checkIn_RoomInitialStatus_RoomIsOccupiedAndDirty() {
    // Arrange
    Room room = new Room(2, 100.0);

    // Act
    room.checkIn();

    // Assert
    assertTrue(room.isOccupied());
    assertTrue(room.isDirty());
}

Three blocks, in order, every time. Arrange sets up the object, Act calls the one method under test, Assert verifies the outcome. Blank lines between the blocks make tests readable at a glance.

Test naming pattern — the 3 parts

1. Method under test

methodUnderTest

checkIn

2. State / scenario

StateUnderTest

RoomInitialStatus

3. Expected behavior

ExpectedBehavior

RoomIsOccupiedAndDirty

checkIn_RoomInitialStatus_RoomIsOccupiedAndDirty

Other styles exist (e.g. shouldX_whenY_thenZ). Pick one for your project — and stick with it. Consistency beats cleverness.

Common assertions

Method	When to use	Example
assertEquals(expected, actual)	Comparing two values for equality — numbers, strings, anything with `.equals()`.	assertEquals(100.0, room.getRate());
assertNotEquals(expected, actual)	Verifying two values are different.	assertNotEquals(0, list.size());
assertTrue(boolean)	Verifying a condition is true — mostly boolean getters.	assertTrue(room.isOccupied());
assertFalse(boolean)	Verifying a condition is false.	assertFalse(room.isDirty());
assertArrayEquals(expected, actual)	Comparing two arrays element-by-element.	assertArrayEquals(new int[]{1,2,3}, result);
assertNull(actual)	Verifying a value is `null`.	assertNull(repo.findById(999));
assertNotNull(actual)	Verifying a value is NOT `null`.	assertNotNull(repo.findById(1));
fail(message)	Explicitly fail a test — useful in unreachable branches.	fail("Should have thrown an exception");

One test, one scenario

Each @Test method tests ONE thing. If you find yourself writing two // Act sections in the same method, split it into two tests with two clearly-named methods. A failing test should point you at exactly one bug.

// BAD — two acts, two scenarios in one test
@Test
public void checkInAndCheckOut_works() {
    Room room = new Room(2, 100.0);
    room.checkIn();                 // Act #1
    assertTrue(room.isOccupied());
    room.checkOut();                // Act #2 — split this!
    assertFalse(room.isOccupied());
}

// GOOD — two tests, one scenario each
@Test
public void checkIn_EmptyRoom_RoomIsOccupied() { ... }

@Test
public void checkOut_OccupiedRoom_RoomIsEmpty() { ... }

Comment style

The AAA comments are PascalCase — capital first letter, no extra words.

// Arrange     ← correct — capital A
// Act         ← correct — capital A
// Assert      ← correct — capital A

// arrange     ← wrong
// act         ← wrong
// assert      ← wrong

Running tests in IntelliJ

Ctrl+Shift+F10

Windows / Linux — run the test method (or class) at the cursor.

Ctrl+Shift+R

macOS — run the test method (or class) at the cursor.

Shift+F10

Re-run the last test you ran (Win/Linux). Mac: Ctrl+R.

Green check ✓ = test passed. Whole class passes when every method shows green.

Red X ✗ = test failed. IntelliJ shows the stack trace and a side-by-side Expected vs Actual diff. Read the diff first — it almost always tells you exactly what's wrong.