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.6 KiB
1.6 KiB
IceCreamForecasting — Split Loop with Lambda (exercise)
Pre-factored variant of IceCreamForecasting-Refactoring-Kata: the Q1/Q4 dead branch is stripped and the hardcoded dates are a constant now. Everything else — including the noise in the scoring loop — is untouched.
Task
longRangeForecast() is hard to test: it calls scorer, and Scorer
stands for an external weather service you must not call from a unit test.
The rest of the method's inputs are only DATES and ANCHOR_DATE.
Get it under test:
- First get any test running that calls
longRangeForecast()— it will fail or be flaky, because of the dependency onScorer. - Then use the Split Loop with Lambda mechanics (6 steps, on the handout) so that the weather collection becomes an extracted method that takes the weather-reading as a lambda parameter.
- Stop when you have an extracted method that takes the lambda as a parameter,
and a test that passes without touching
Scorer.
Constraint
Don't change Scorer and don't change the behaviour of
longRangeForecast(). Compile early, compile often.
Debrief questions
- At which step did plain Split Loop stop working, and why? (Hint: what type did your introduced variable end up being?)
- There are two calls to
scorerin the weather loop. What did you do with each one? - Could you delete either call without changing the forecast? Try it. Why did that work?
- Where would you take this next — more extraction, or moving the method
to another class where
Scoreris unknown?