ruthmoogThe goal is clean code that works
- Ron Jeffries
Chapter 2: Degenerate Objects
Part of the process of writing tests in small steps is iterating to improve and design your code. As a result, the code is easy to understand, and works (at least to your most-current level of understanding).
"Write a test. Make it run. Make it right." It's tempting to make it right before making it run, but then you don't have the safety of your tests to allow you refactor and explore more elegant or efficient solutions.
Beck talks about two strategies to get your tests to run,
- Return a constant and replace with variables one by one until the code works
- Use the real implementation from the start -when it's obvious
I typically use the approach of writing out in plain English my given/when/then scenario, which I can build on with code that returns constants, then build out with code that really works. Most of the time though, the test I'm working out in plain English isn't obvious to me... this seems to be a skill that comes with practise and experience.
Once we decide on the correct behavior, we can talk about the best way of achieving that behavior.
Beck mentions the the habit of TDD creates awareness of when something isn't right in the design (he gives 'disgust at side effects' as an example). This is difficult to hone, but determining the behaviour first is important.
🔎 View my code-along repo at https://github.com/ruthmoog/test-driven-development-by-example
