# Exercise 3 — Buyers (Split Loop with Lambda, the pure rep)

A third, minimal example in the same kata theme: the sellers exist
(`DailyForecasts` — Steve, Julie, Francis), the buyers don't. This adds them:
`Buyers` computes a buyer's shopping-list total, and `PriceList` stands for an
external pricing service (it adds random surge pricing, so the test is flaky).

Written in **C#** (MSTest, .NET 7 — same setup as the kata's `csharp/` folder).
Run with `dotnet test test/BuyersTests.csproj`.

Contents:

- `csharp/` — pristine exercise repo: one loop, **one** lambda-able expression
  (`priceList.PriceFor(flavour)`), nothing else. No printing, no conditionals,
  no void calls.
- `solution/` — end state: extracted static method taking
  `Func<IceCream, int> priceFor`, a no-arg overload passing the method group,
  and a deterministic test with a pure lambda (`_ => 2`).

`IceCream.cs` is copied from
[IceCreamForecasting-Refactoring-Kata](https://github.com/emilybache/IceCreamForecasting-Refactoring-Kata)
(same license as the kata applies).

## Where this sits in the sequence

| example | lambda | teaches |
|---|---|---|
| 1. `longRangeForecast` weather loop (Java) | `LongFunction<Boolean>` | the pattern + the drift trap |
| 3. `Buyers` shopping list (C#, this one) | `Func<IceCream, int>` | the move in its purest form: one expression, nothing else |
| demo/next: `printSalesForecasts` → `SalesScorer`, `PriceList` → `Pricing` | role interface | when one function isn't enough (two side-effectful methods to stub) |

Next-time arc: marketing adds surge discounts, `PriceList` grows
`DiscountFor(...)` — two methods to stub → extract a role interface
(`IPricing`) instead of two lambdas. See the demo script's closing note.

## Not verified by a build

This exercise was authored without a local .NET SDK (structurally mirrored from
the kata's `csharp/` project files). Run `dotnet test test/BuyersTests.csproj`
once on a machine with the SDK before facilitating.