A feature can pass its business-facing checks yet still leave developers unsure which component needs changing when the requirement shifts. A unit test narrows that question: it describes and verifies the behavior of an individual component, such as a method or function. Unlike an acceptance test, which checks a feature in terms users and sponsors recognize, a unit test is written by developers for developers. section 2.1 section 3.7
In an outside-in workflow, acceptance criteria establish the expected feature outcome. Developers then write low-level tests for the component behavior needed to produce it. The test specifies what should happen for a particular input or situation; the developer writes enough code to make it pass and refactors afterward. This keeps implementation tied to the feature rather than to a list of classes that happen to exist. section 2.1 section 2.3.7
A requirement changes from two trains to four
Suppose a journey planner currently proposes the next two departures, but users now need four. First change the acceptance criterion so it expects four; its failure exposes the gap. Then update the unit test for proposing departures. That test points to the service behavior that needs changing and verifies the result at component level. section 3.7
@Test
@DisplayName("should propose the next 4 trains")
void tripWithSeveralScheduledTimes() {
timeTable
= departures(
at("8:10"),at("8:20"),at("8:30"),at("8:45"),at("8:45")); #1
itineraries = new ItineraryService(timeTable);
List<LocalTime> proposedDepartures
= itineraries.findNextDepartures(at("8:05"), "Hornsby", "Central");
assertThat(proposedDepartures)
.containsExactly(at("8:10"), at("8:20"), at("8:30"),at("8:45")); #2
}
The unit-test listing supplies departures, calls the itinerary service, and asserts the four results required by the changed criterion. section 3.7
A useful unit test is also a worked example for a future maintainer. Names such as “When creating a new account” and “A new account should have an initial balance” make the behavior discoverable; the assertion shows what balance to expect. Favor tests that demonstrate how to use a component over tests coupled to its protected fields or a rigid one-test-class-per-production-class structure. Implementation-focused tests can become brittle when classes are refactored. section 2.3.7 section 16.5.5
Choose the level of test deliberately. Detailed input rules need not each run through a web interface: a lower-level unit testing library can check cases that do not merit business-facing living documentation. For an existing application, adding meaningful unit tests after the fact can be difficult because expected component behavior may be undocumented. Start with critical or high-risk behavior when that investment is worthwhile. section 10.2.4 section 16.6
