TDD: How to keep it from going wrong (Part 1: Introduction)
Preface
I’ve been practicing TDD for a while now. Along the way my view on how to practice TDD has shifted a lot. Lately I’ve given some training sessions on TDD and refactoring, which allowed me to refine my views on what I think is doing TDD the ‘right’ way. When I look around the internet I still see alot of people explaining TDD in a way that can be demotivating for someone who is new to the subject or can even be damaging to a project (I’ve experienced this hands on).
In this series I wanted to delve into what I consider good TDD.
References
The posts are heavily inspired by
- Ian Coopers talk TDD: Where did it all go wrong and Decoupling from ASP.NET
- The Is TDD dead talks by Kent Beck, Martin Fowler and David Heinemeier Hansson
- Still the best book on the subject: TDD by example by Kent Beck
What we’ll see
First we’ll go back to basics and ask ourselves why we do TDD. We’ll see what benefits good TDD can bring and explore some of the misconceptions. Next we’ll delve into the concept of mocking and why abuse of it can be damaging. Finally we’ll wrap things up with a short look at the hexagonal architecture.
Posts in this series
- Part 1: Introduction
- Part 2: What is TDD and why do we it
- Part 3: When you’re using it wrong
- More to appear soon…