HanLHo. - Fractional Architect & Software Product Engineer - gherkin

Notes on 🚀 TDD, Where Did It All Go Wrong

2024-11-14T00:00:00+00:00

My short notes on 🚀 TDD, Where Did It All Go Wrong</a>.</p>

Still a lot of testing wisdom in this talk (re-watched 6 years after publication).</p>

Focus on behaviour</h2>
Behaviour should be your primary focus when writing tests. The need for a new test should arise from new behaviour or requirements. While TDD is often contrasted with BDD, Kent Beck's early work already emphasised the importance of focusing on behaviour.</p>
When writing tests, be mindful of coupling. Your tests should not all fail when you change your code. Write tests against public contracts where possible. In my experience, you can deviate from this rule if your unit under test has a stable internal contract.</p>
This approach leads to better 'refactorability'. For a practical demonstration, I recommend watching TDD & DDD From the Ground Up Live Coding by Chris Simon</a>.</p>

ATDD tools are not worth it if business is not actively participating</h2>
While I have promoted the use of ATDD (Acceptance Test Driven Development) tools like Gherkin, I must agree, the burden of translating between natural language and code can be 'horrible', to the point where internal frameworks are implemented to manage this complexity.</p>
More importantly, the effort may not be worthwhile without an engaged business analyst or product owner. In my experience, business stakeholders rarely show interest in participating. While I've questioned whether I could have done more to encourage engagement, this talk confirms this is a common challenge. Though disappointing to acknowledge, as the practice appears promising on paper, this seems to be the reality we face.</p>
That said, the consistent style these tools promote can still be valuable in test writing.</p>
If you had success using Gherkin or similar tool I would be interested in learn how.</p>
Do not forget about Refactor</h2>
The TDD-cycle is Red-Green-Refactor</strong>. First fix the problem, then improve the design. The central idea is to decouple thinking about the problem from thinking about the design. The Refactor step is where the design is improved and is an integral part of the cycle.</p>
This methodical approach leads to more maintainable code, contrasting with the approach of the 'Duct-tape Programmer' (this talk) or 'Tactical Tornado' (Ousterhout</a>) approach.</p>
When you can improve the design without changing tests, you have achieved good decoupling.</p>