Your Name
a27e32688a
- 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
1.4 KiB
1.4 KiB
Reference solution — end state after step 3
Derived from 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
- Weather loop extracted to
collectExpectedWeather(LongFunction<Boolean>)— a static method whose only "unwanted dependency" is the lambda parameter. - Public no-arg
longRangeForecast()delegates to a new overload that takes the weather function, keeping existing callers working. - Test passes a pure lambda (
daysForward -> true) — the original test called the no-arg method and was flaky because ofScorer'sRandom.
Variations to try (for the debrief or a second round)
daysForward -> false(no sunny holidays): scores drop to+10only.daysForward -> daysForward == 5(exactly one sunny holiday, and it is notexpectedWeather.get(1), so no+2): all flavours10.- Delete the
scorer.updateSelection()call inside the production lambda: the approved file does not change — the forecast never readsScorer.flavour. - Variation end state: skip the overload; make
collectExpectedWeatherpackage-private and test it directly with pure lambdas. Trade-off: tests the pure slice but not the composition (scoring loop).