An evaluation scenario is the particular situation used to check software behavior: the inputs or conditions supplied to a feature, and the behavior expected in response. A useful test makes the scenario visible rather than hiding it inside the test code. section 2.5.3 section 9.1
A scenario is not the whole test. It is the “with” part: for example, calling a function with a failing rule or a null value. Pair it with the unit under test and the expected result, so a failing test name points toward the likely problem without requiring someone to open the test. section 2.5.3 section 9.1
Make the scenario readable
Name the condition directly: `verifyPassword, given a failing rule, returns errors`. Here, `verifyPassword` is the unit, “given a failing rule” is the scenario, and “returns errors” is the expectation. The fake rule makes the condition concrete and the assertion checks its visible result. section 2.5.3
Plan scenarios just before implementing a feature or user story, preferably with another person. Decide which test level best fits each one. Lower-level tests are generally faster; use higher-level tests when they are necessary for confidence. section 10.3.2 section 10.3.3
Keep a scenario set useful by following these practical checks:
- Add scenarios until passing them gives confidence that the feature works; revise the list as implementation reveals gaps. section 10.3.3
- Avoid duplicating the same scenario across existing tests or multiple test layers; test meaningful variations at lower levels when possible. section 10.3.3
- Do not require every feature to have tests at every level; choose the mix that balances confidence, speed, and maintenance burden. section 10.3.3
- Keep the scenario near the reader’s eyes, in a test name or nested grouping, alongside the unit and expected behavior. section 9.1 section 9.5
Listing 2.5 Naming a test with USE
test('verifyPassword, given a failing rule, returns errors', () => {
const fakeRule = input => ({ passed: false, reason: 'fake reason' });
const errors = verifyPassword('any value', [fakeRule]);
expect(errors[0]).toContain('fake reason');
});
This small test shows a scenario expressed in a USE-style name and embodied by a fake failing rule. section 2.5.3
