When do we make design decisions inside a TDD red-green-refactor cycle?

When do we make design decisions inside a TDD red-green-refactor cycle?

In Mockist TDD, we’re making all decision decisions early, when we’re in RED. This is because when we’re writing a test for a class, we’re already thinking about its collaborators, we’re thinking about the responsibilities of our class versus the responsibilities of the collaborators, and we’re designing HOW they will communicate. Essentially, we’re translating CRC cards into tests. Our tests are communicating our class decision decisions, how our class passes messages to its collaborators, i.e. how it interacts with its collaborators.

In Classicist TDD, we make most of the design decisions later, when we’re in GREEN and REFACTOR. The only decision decisions we make in RED is if our class collaborates with shared dependencies (so we then have to be aware of repository interface, for example) but we do NOT care about any other collaborators of the class. So then in GREEN, we make the simplest possible decision decisions (actually we can even write really badly designed code, it’s alright!) to make the test pass. Then in REFACTOR, we can change our design decisions by (for example splitting our class into smaller classes, so we’re now introducing collaborators). The test is unaffected because the test doesn’t communicate decision decisions.

To summarize:
– In Mockist TDD, the class interaction design decisions are visible in the test itself, in fact, we’re designing the interactions through the test, i.e. early design.
– In Classicist TDD, we do NOT communicate the class interaction design decisions in the test, but rather in the code, we can thus do late design decisions without affecting the test.

This is why, if you change CRC cards, you break tests done in the Mockist TDD style but not in Classicist style. Classical TDD cares only about the end behavior, not the inter-class interactions.