There are two big schools of TDD, and most devs end up in one without ever really picking sides. Quick recap: London-style (mockist) drives design by mocking collaborators and asserting on interactions. Chicago-style (classicist) builds from the inside out using real objects and asserting on values and state. I'm firmly in the Chicago camp. Here's why, and how it pairs really nicely with hexagonal architecture. Mocks belong at boundaries. That's it. I'm not anti-mock. Mocks are great when you're crossing a boundary you don't control or don't want to hit in a test: the database, an HTTP API, a message queue, the clock, the filesystem. Anything where the alternative is slow, flaky, or has side effects you can't take back. Inside the boundary? Use real objects. If two domain classes collaborate, let them collaborate. Build them up, call the method, assert on what came out. That's the test.…