- Samman learning hour: 5/5/10/25/5 outline; pairs stop at extracted method taking the lambda as a parameter - exercise/java: pre-factored variant of the kata (Q1/Q4 dead branch stripped, dates as constant), approval test red/flaky by design - exercise/solution: collectExpectedWeather(LongFunction<Boolean>) + no-arg overload; deterministic approval test (all-sunny lambda) - rehearse-with-agent.md: rehearsal setup with qwen + java-refactoring-mcp
28 lines
1.4 KiB
Markdown
28 lines
1.4 KiB
Markdown
# Reference solution — end state after step 3
|
|
|
|
Derived from [IceCreamForecasting-Refactoring-Kata](https://github.com/emilybache/IceCreamForecasting-Refactoring-Kata)
|
|
(same license as the kata applies to the copied `IceCream.java`).
|
|
|
|
Run with `mvn test` — the approval test passes deterministically without
|
|
touching the weather service.
|
|
|
|
## What changed vs the exercise start
|
|
|
|
1. Weather loop extracted to `collectExpectedWeather(LongFunction<Boolean>)`
|
|
— a static method whose only "unwanted dependency" is the lambda parameter.
|
|
2. Public no-arg `longRangeForecast()` delegates to a new overload that takes
|
|
the weather function, keeping existing callers working.
|
|
3. Test passes a pure lambda (`daysForward -> true`) — the original test
|
|
called the no-arg method and was flaky because of `Scorer`'s `Random`.
|
|
|
|
## Variations to try (for the debrief or a second round)
|
|
|
|
- `daysForward -> false` (no sunny holidays): scores drop to `+10` only.
|
|
- `daysForward -> daysForward == 5` (exactly one sunny holiday, and it is not
|
|
`expectedWeather.get(1)`, so no `+2`): all flavours `10`.
|
|
- Delete the `scorer.updateSelection()` call inside the production lambda:
|
|
the approved file does not change — the forecast never reads `Scorer.flavour`.
|
|
- Variation end state: skip the overload; make `collectExpectedWeather`
|
|
package-private and test it directly with pure lambdas. Trade-off:
|
|
tests the pure slice but not the composition (scoring loop).
|