Testing exceptions

Written Explanation

Why test the unhappy path

Imagine Account.withdraw without its overdraft check. All of your "happy" tests (deposit, normal withdraw) still pass, and the bank now lets customers spend money they do not have. A test for the rejection is the only thing that notices when that check disappears. For each rule that says "must be rejected", write a test that proves it.

assertThrows

@Test
void withdrawOfNegativeAmountIsRejected() {
    Account account = new Account("Sam", 100);
    assertThrows(IllegalArgumentException.class, () -> account.withdraw(-1));
}

assertThrows(ExceptionType.class, code) runs code and passes only if that code throws an exception of the given type. The second argument is a lambda: () -> account.withdraw(-1) means "a piece of code with no inputs, to be run later by assertThrows". The lambda is needed because the call must happen inside assertThrows, where JUnit can catch the exception. If you wrote account.withdraw(-1) as a normal statement before it, the exception would escape and the test would fail with an error instead.

Notice that the test still follows the AAA shape: Arrange (the account), then Act and Assert together, because the call and the check are one statement.

The test fails in two ways

assertThrows fails if:

1. No exception is thrown. Real output when we asked for IllegalArgumentException from a valid deposit(5):

org.opentest4j.AssertionFailedError: Expected java.lang.IllegalArgumentException to be thrown, but nothing was thrown.

1. A different type is thrown. Real output when we expected InsufficientFundsException from withdraw(-1) (which really throws IllegalArgumentException):

org.opentest4j.AssertionFailedError: Unexpected exception type thrown, expected: <InsufficientFundsException> but was: <java.lang.IllegalArgumentException>

Both failures are informative: they say what you expected and what happened.

A subtlety: a subtype is accepted. In our run, assertThrows(RuntimeException.class, () -> account.withdraw(-1)) passed, because IllegalArgumentException is a kind of RuntimeException. That makes a too-general type a weak test. Name the most specific type your code promises. (JUnit also has assertThrowsExactly for an exact match, which we do not need yet.)

Checked exceptions need no extra code

InsufficientFundsException is checked, and withdraw declares it. You might expect to wrap the call in try/catch. You do not: the lambda that assertThrows accepts is allowed to throw anything. Inside assertThrows(InsufficientFundsException.class, () -> account.withdraw(150)) the code compiles as written.

If you call withdraw directly in a test (for a normal, allowed withdrawal), the compiler does require you to deal with the checked exception. The simplest way is to declare throws InsufficientFundsException on the test method:

@Test
void withdrawSubtractsFromBalance() throws InsufficientFundsException {
    Account account = new Account("Sam", 100);
    account.withdraw(40);
    assertEquals(60, account.getBalance());
}

If the exception is thrown unexpectedly, JUnit reports the test as failed with that exception, which is what you want.

Checking the message and data

assertThrows returns the exception that was thrown, so you can look at it:

InsufficientFundsException e = assertThrows(InsufficientFundsException.class,
        () -> account.withdraw(150));
assertEquals("Cannot withdraw 150.00: balance is only 100.00", e.getMessage());
assertEquals(50, e.getShortfall(), 0.001);

Use this when the message or data is part of the promise. Do not check the exact message text just for decoration, since it makes the test break whenever someone improves the wording. (Also note: the course's exception builds its message with String.format("%.2f"), which on a computer with certain regional settings may print a comma instead of a decimal point, so a test that compares the whole message text can fail on such a machine. The shortfall check has no such risk.)

Reject, and leave things unchanged

A refused operation should not half-succeed. After the rejection, check the state:

@Test
void rejectedWithdrawLeavesBalanceUnchanged() {
    Account account = new Account("Sam", 100);
    assertThrows(InsufficientFundsException.class, () -> account.withdraw(150));
    assertEquals(100, account.getBalance());
}

Here the Act-and-Assert of the exception is followed by a second assertion about the same behavior ("a rejected withdrawal changes nothing"). This is one reason to fail, as lesson 2 allows.

One bad case per test

Write a separate test for each bad input: a negative amount, a zero amount, an overdraft. If you put three assertThrows calls in one test, the first failure hides the others, and the name no longer says which case broke.

A quick recipe

For any "must be rejected" rule, follow four steps: (1) write the rule as a sentence ("withdrawing zero is rejected"); (2) turn the sentence into a method name; (3) arrange the smallest object that makes the rule matter (here, an account with 100); (4) put the one call that should fail inside the lambda. Then deliberately remove the check from the code, run the test, and confirm it goes red. A test you have never seen fail is a test you have not yet shown to work.