Java Guild course · Lesson 0006

Lesson 0006 · design under pressure

Making Main Testable

A 90-line static method with a hardcoded Scanner, a giant switch, and a crash on any keypress that is not a digit.

Main is where most candidates stop, because it works when you type carefully. It is also the class that most directly answers the criterion “proper use of object-oriented programming principles” — and right now it has almost none.

Start with the crash

Exception in thread "main" java.util.InputMismatchException
	at java.base/java.util.Scanner.throwFor(Scanner.java:977)
	at java.base/java.util.Scanner.nextInt(Scanner.java:2251)
	at com.solirius.intermediate.library.Main.main(Main.java:72)

One stray keypress kills the application. And because the state file is only written by menu option 6, everything added during that session is lost. The brief asks you to handle edge cases; a user mistyping a menu choice is the most ordinary edge case a console program has.

The fix is not hasNextInt()

The instinctive fix has a trap in it:

while (!scanner.hasNextInt()) {
    System.out.println("Invalid choice.");
    // the bad token is still sitting in the buffer -> infinite loop
}

hasNextInt() does not consume anything. Unless you also call scanner.next() to discard the offending token, this spins forever printing the message. Reading a whole line and parsing it yourself avoids the trap entirely, and handles "3 ", "" and "banana" the same way:

String input = in.nextLine();
MenuOption chosen = MenuOption.from(input).orElse(null);   // null => not a valid choice

The design move: an enum instead of six constants

The starter has six public static final int fields and a MENU string that repeats all six labels. Two lists that must be kept in step by hand — add an option and forget the string, and the feature is invisible.

public enum MenuOption {
    ADD_BOOK(1, "Add a new book"),
    VIEW_AVAILABLE(2, "View available books"),
    SEARCH(3, "Search for a book"),
    BORROW(4, "Borrow a book"),
    RETURN(5, "Return a book"),
    EXIT(6, "Exit");

    public static Optional<MenuOption> from(final String input) { ... }
    public static String menu() { ... }   // renders from values()
}

The other design move: stop reaching for global state

Main reads System.in and writes System.out directly, from a static method. That is why it cannot be tested: there is no seam to push a fake through. Take the streams as constructor parameters:

public LibraryConsole(final Library theLibrary,
                      final Scanner input,
                      final PrintStream output) { ... }

This is constructor injection — dependency injection with no framework, no annotations and no container. And it is what makes this possible:

private String runWith(final String input) {
    ByteArrayOutputStream captured = new ByteArrayOutputStream();
    new LibraryConsole(
        new Library(),
        new Scanner(new ByteArrayInputStream(input.getBytes(UTF_8))),
        new PrintStream(captured, true, UTF_8)
    ).run();
    return captured.toString(UTF_8);
}

@Test
@DisplayName("asks again when the choice is not a number")
void asksAgainWhenTheChoiceIsNotANumber() {
    assertTrue(runWith("banana\n6\n").contains("Invalid choice. Please try again."));
}

The red bar

Write that test against a straight extraction of the existing logic — still using nextInt() — and the crash moves out of the terminal and into the build, which is exactly where you want it:

[ERROR] LibraryConsoleTest.asksAgainWhenTheChoiceIsNotANumber <<< ERROR!
java.util.InputMismatchException
	at LibraryConsoleTest.runWith(LibraryConsoleTest.java:23)

Then switch to line-based parsing and it goes green.

Where Mockito fits — and where it does not

The pom declares mockito-core and nothing uses it. It is tempting to reach for it here to prove you can. Resist.

Drill

Commit it — as two commits

Extract LibraryConsole from Main so the menu can be tested

Main read System.in and wrote System.out from a static method, so the
menu loop had no seam a test could reach. LibraryConsole takes its
Scanner and PrintStream as constructor parameters; Main is reduced to
wiring and no longer contains behaviour.

No functional change: the golden master is unchanged by this commit.

Handle menu input that is not a number

Typing any non-digit at the menu raised InputMismatchException and
terminated the application, discarding everything added during that
session, since state is only written on a clean exit.

The choice is now read a line at a time and matched against MenuOption,
which also replaces the six int constants and the hand-maintained menu
string. The menu is rendered from the enum, so an option cannot exist
without appearing on screen.

Read this

Carry on

• Reference card: Design decisions & how to defend them
• Next: Lesson 0007 — The Commit Log Is Part Of The Submission

Send me your LibraryConsole and I will review it as an assessor would — the first thing I will look for is whether anything in it still mentions System.