Why can a pure renewal core be tested without standing anything in for the clock or the account store?

## Why there is nothing to stand in for A substitute is something you supply so that a call the code makes goes somewhere you control. A pure decision core makes no such call. Its dependencies are not reached for — they were **handed in**: the account records, the price, the instant, any random value already drawn. There is nothing to intercept, so there is nothing to supply. That changes what a test *is*. Instead of arranging a world and then asserting about it, the test states a relation between two values: - **Given** these records and this instant - **Expect** exactly these decisions The whole fixture is data, and the assertion compares data. That is why this style of test tends to collapse into a table of cases: each row is inputs and expected output, and adding a rule means adding rows. ## What you stop paying for - **Setup and teardown.** There is no world to build or dismantle, so cases have no prologue. - **Ordering.** No case can leave residue for the next, because nothing was written. - **Flakiness from time.** The instant is a literal, so a case that exercises a renewal boundary behaves the same in March and in December. - **Reproduction cost.** A failing case is fully described by its arguments; pasting them back reproduces it exactly. - **Concurrency limits.** Cases can run at once, because they share nothing. One caution against overstating it: fast and repeatable is not the same as *correct*. A core test proves the rule does what you said, not that what you said is the rule the business wanted. ## Where the remaining tests go | what is checked | where it runs | character | |---|---|---| | the rules themselves | core, over literal values | fast, repeatable, many cases | | wiring: right rows loaded, every returned decision performed | outer layer | fewer, slower, needs a boundary | | the boundary itself behaves as assumed | against a real dependency | fewest, slowest | The split is the point: the layer with the most cases is the one with the lowest cost per case, and the layer that costs the most per case carries the fewest. Before the rules were isolated, both roles belonged to the same slow tests, which is why suites in that shape grow minutes and then hours. ## What the fast cases cannot see Be precise about the hole you are leaving, because it is real: - The outer layer loading the wrong set of accounts — the core happily decides about whatever it is given. - A returned decision that is dropped, or performed twice after a retry. - A field mapped wrongly on the way in, so the core reasons about a plausible but wrong record. - The dependency at the boundary behaving differently from your assumption. None of those are rule bugs, and none of them will ever turn a core test red. They are exactly why a handful of tests over the outer layer stay worth their cost, and why "we moved the logic into a pure core" is not an argument for deleting them. ## A useful side effect on the design Writing these tests exerts steady pressure back on the arrangement. If a case needs a fixture, something in the path reads; if a case has to run before another, something writes; if a case is hard to state as values, the function is probably deciding and acting at once. In that sense the test difficulty is a measurement, not an obstacle — a rule that suddenly needs a stand-in is telling you a read has crept back into the core, usually the day someone needed one more record mid-decision. Finally, the arrangement makes a stronger kind of check affordable. Because the core is a function of its arguments, you can assert relations across many generated inputs — that no cancelled account is ever charged, that the total charged equals the sum of prices of exactly the due accounts — without building a world for each one. That style is expensive against a real boundary and nearly free against a pure function.