Files

T

Your Name a27e32688a Add split-loop-with-lambda learning hour: draft, pre-factored exercise, solution

- 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

2026-09-27 13:30:00 +00:00

src

Add split-loop-with-lambda learning hour: draft, pre-factored exercise, solution

2026-09-27 13:30:00 +00:00

.gitignore

Add split-loop-with-lambda learning hour: draft, pre-factored exercise, solution

2026-09-27 13:30:00 +00:00

pom.xml

Add split-loop-with-lambda learning hour: draft, pre-factored exercise, solution

2026-09-27 13:30:00 +00:00

README.md

Add split-loop-with-lambda learning hour: draft, pre-factored exercise, solution

2026-09-27 13:30:00 +00:00

README.md

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 on Scorer.
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 scorer in 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 Scorer is unknown?