Workbook 4a — Module 3 — Exercise 1

hotel-operations Unit Tests

Lock down Room and Employee behavior with JUnit | Workbook p.68

The Exercise

Now that Room and Employee have real behavior, write JUnit tests that prove they work the way you expect — and keep working as the code changes.

For RoomTest, write tests that exercise checkIn(), checkout(), and cleanRoom(). How many tests do you need? Think about the edge cases: should you be able to check in to a room that's already occupied? Or one that's still dirty? Should housekeeping be able to clean a room while a guest is in it?

For EmployeeTest, test that punchIn(int) stores the start time, and that punchOut(int) calculates hours worked correctly. Skip the no-arg overloads — those depend on the current time and are hard to test reliably.

Test Scenarios to Think About

When you call checkIn() on a fresh, clean Room, what should be true afterwards?
When you call checkout(), what changes? What stays the same?
Can you clean a room that's currently occupied? What should happen if you try?
If the employee punches in at 9.0 and punches out at 17.5, what should hoursWorked equal?
What happens if a fresh Room (clean and empty) is asked to cleanRoom() — is that a problem or a no-op?

Suggested Test Names — 3-Part Pattern

The Pattern

methodUnderTest_StateUnderTest_ExpectedBehavior

@TestcheckIn_RoomInitialStatus_RoomIsOccupiedAndDirty()
@Testcheckout_RoomIsOccupied_RoomIsNotOccupied()
@TestcleanRoom_RoomIsOccupied_RoomRemainsDirty()
@TestcleanRoom_RoomWasPreviouslyUsed_RoomIsNotDirty()
@TestpunchIn_StartTimeNotSet_StartTimeSetToGivenTime()
@TestpunchOut_HoursNotSet_HoursWorkedSetCorrectly()

Names only — you write the body. Each name reads like a one-line spec: what method, in what state, expecting what?

Concepts You'll Use

Flow

1Open Room.java → right-click → Generate → Test

→

2Pick JUnit6, fix dependency if prompted

→

3Plan your scenarios on paper first

→

4Name each test using the 3-part pattern

→

5Inside each: Arrange, Act, Assert

→

6Repeat for EmployeeTest

→

7Run all tests — green checks for each

Tip — Pick a Style and Stick With It

Naming consistency matters. The 3-part pattern methodUnderTest_StateUnderTest_ExpectedBehavior reads like a tiny spec at a glance. Other styles work too — shouldDoX_whenY, given_when_then, plain English — just don't mix them inside one project. When a test fails, the name should tell you exactly what broke without opening the file.

Workbook 4a, p.68 — Module 3, Exercise 1: hotel-operations Unit Tests