If you know which direction you’re going, you write tests and then code and then refactor, in a tight feedback loop.
If you don’t know which direction to go, you do a “spike” (a term you’ve probably heard being completely misused) and write just enough code to figure out which direction you want to go.
Crucially, you’re not trying to write code you intend to keep. You might assimilate some parts later on, but count on deleting/abandoning the vast majority of it.
This is just about picking a direction for your next test. Naming, encapsulation, testability, DRY, error-handling, etc. are all irrelevant and even counterproductive in this context.
In this way, you can alternate between three essential modes:
Am I moving in the right direction? (Spike)
How do I want this component to behave? (Test+Code cycle)
How do I want to manage the implementation of this component? (Refactor)
If you’re doing this really, really well then your spikes and test+code cycles will be focused on use cases rather than developer-oriented concerns.
On a broader note, I hate the term “test” when it comes to the TDD style of development. It implies something that is done at the end of an assembly line, in deep detail, to ensure quality or compliance.
Testing in TDD is much more like sitting down at a blank piece of paper and asking “Okay, if I didn’t have to worry about how to implement this component, how would I want it to use it?” and writing some concise examples of how it would behave.
Kent Beck’s TDD accounts for this.
If you know which direction you’re going, you write tests and then code and then refactor, in a tight feedback loop.
If you don’t know which direction to go, you do a “spike” (a term you’ve probably heard being completely misused) and write just enough code to figure out which direction you want to go.
Crucially, you’re not trying to write code you intend to keep. You might assimilate some parts later on, but count on deleting/abandoning the vast majority of it.
This is just about picking a direction for your next test. Naming, encapsulation, testability, DRY, error-handling, etc. are all irrelevant and even counterproductive in this context.
In this way, you can alternate between three essential modes:
If you’re doing this really, really well then your spikes and test+code cycles will be focused on use cases rather than developer-oriented concerns.
On a broader note, I hate the term “test” when it comes to the TDD style of development. It implies something that is done at the end of an assembly line, in deep detail, to ensure quality or compliance.
Testing in TDD is much more like sitting down at a blank piece of paper and asking “Okay, if I didn’t have to worry about how to implement this component, how would I want it to use it?” and writing some concise examples of how it would behave.