Testing Exceptions

@isTest
static void checkOutAlreadyBorrowedBookThrows() {
    Book__c book = new Book__c(Title__c = 'Test Book', ISBN__c = '123', Is_Checked_Out__c = true);
    insert book;

    LibraryService library = new LibraryService();

    try {
        library.checkOutBook(book.Id, 'Amara Nkosi');
        System.assert(false, 'Expected a LibraryException to be thrown');
    } catch (LibraryException e) {
        System.assert(e.getMessage().contains('already checked out'));
    }
}

System.assert(false, ...) right after the call being tested is a deliberate trick: if checkOutBook doesn't throw, execution reaches that line and the test fails with a clear message — if it does throw (as expected), that line is never reached, and the catch block verifies the exception's details instead.

@isTest
static void checkOutAvailableBookSucceedsWithoutException() {
    Book__c book = new Book__c(Title__c = 'Test Book', ISBN__c = '123', Is_Checked_Out__c = false);
    insert book;

    LibraryService library = new LibraryService();

    Checkout__c checkout = library.checkOutBook(book.Id, 'Amara Nkosi');

    System.assertNotEquals(null, checkout.Id);
}

This test doesn't wrap the call in try/catch at all — if checkOutBook unexpectedly threw an exception here, the test would simply fail with that uncaught exception, which is exactly the correct behavior: an available book checking out successfully should never throw.

It's easy to write a test only for the "happy path" (Module 12's term) and never verify the error-handling branches at all — meaning a bug in the exception logic itself (a wrong message, a missed edge case, or worse, an exception that should fire but silently doesn't) can ship straight to production undetected. Explicitly testing both "throws when it should" and "doesn't throw when it shouldn't" closes this exact gap.