One new interface method sends a Dart TDD loop back through build_runner

The closure is doing all the work here. Under sound null safety, `when(mock.getUser())` evaluates the call first, so `noSuchMethod` has to hand back a `User` before any stub exists to supply one, and returning null throws before the stubbing logic runs ^[5]. mocktail writes the same intent as `() => mock.getUser()` ^[12]. The library takes the closure, puts its interception in place, then invokes it, so by the time the call happens there is a registered stub or a fallback value to return ^[12]. No generated sibling file is needed, because in Dart every class implicitly defines an interface and a mock can implement one without inheriting its implementation ^[11].

Dart deliberately avoids heavy runtime reflection, and `dart:mirrors` is disabled in Flutter for performance and tree-shaking ^[6]. With reflection unavailable, mockito took the route that was left: compile-time generation through build_runner ^[6].

The timings in the post are one developer's experience, not a measurement anyone can replay. He gives 15 seconds, 30 seconds, and maybe two full minutes on a large enterprise Flutter codebase ^[3]. The top of that range is eight times the bottom ^[14]. For the two-minute figure to describe your repository, you would need a comparable count of annotated classes and a comparable set of builders in the pipeline; the post does not say whether those runs were cold or incremental. The 15-second figure is the safer one to plan around.

What makes the tax recurring is the trigger. It fires on the interface edit, so how often you pay is set by how you work ^[1]. Ten regenerations in a day at 30 seconds each is five minutes of waiting, and ten is a normal day for anyone running red-green-refactor against a service layer ^[15].

Switching costs something too. Every `when` and `verify` call site changes shape, since the invocation has to become a closure ^[12]. The `@GenerateMocks` lists come out, and the imports of the generated symbols go with them ^[8][10].

In my view a Flutter app with a fast-moving service layer is better off with the closure. Typing `() =>` costs a keystroke and some unfamiliarity at review; reviewing a few thousand lines of machine-generated boilerplate is nobody's favourite part of a pull request ^[7]. Where interfaces are stable and the mock list rarely changes, the build cost amortises and this argument gets much weaker. The post's own framing is a flow-state one: it says feedback loops that stretch into tens of seconds lead developers to batch their changes and commit without verifying, with tests run as an afterthought ^[13].