Why TDD Katas don't work
TDD Katas are useful. But TDD Katas don't translate to real-life practice.
👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
Katas are popular
A common approach to learning TDD is using TDD Katas. TDD Katas are simple exercises to help us practice TDD. If you're completely new to TDD, popular katas include:
You'll find TDD Katas in many TDD courses, e.g. in Uncle Bob's Clean Coders courses (e.g. FizzBuzz Kata), Dave Farley's TDD courses (e.g. String Calculator Kata).
Why TDD Katas are useful
TDD Katas are useful. They highlight the core principles of the TDD Red-Green-Refactor cycle:
Writing the test before the code
Writing minimal code, just enough to make the test pass
Refactoring to make the code cleaner
The TDD Katas help us work incrementally & iteratively.
They’re good for Learning Hours, because you can easily time-box these exercises.
But TDD Katas don't translate to real-life practice
The problem with TDD Katas is that they only illustrate the lowest-level inner-most TDD cycle. At this lowest level, we jump straight into writing a Unit Test & using it to implement some classes, we jump right into implementing Business Logic.
However, when developers try to apply TDD, they have the following questions:
How do we use TDD to implement the UI? Or is TDD just for Business Logic?
How do we use TDD to implement the REST API? Or does TDD ignore the REST API?
How do we deal with Databases? Or do we ignore Databases because it's just I/O?
How do we deal with Microservices? Or do we just ignore Microservices with TDD?
How do we deal with External Systems? Or do we ignore it because it's just I/O?
How does TDD relate to our real-life workflow:
When we get a User Story, how do we apply TDD?
When we get a Bug, how do we apply TDD?
Those are the questions that many developers ask themselves.
Unfortunately, TDD Katas do NOT provide answers to those questions. TDD Katas have a very narrow focus. They use TDD at the unit test level to implement business logic in classes and methods. They ignore everything else. They do not answer how to handle UIs, REST APIs, databases, microservices, or external systems.
As a Technical Coach, I’ve worked with many teams worldwide. I had no resources to show developers that would answer the questions they had above. The TDD Katas didn't illustrate that. Often, I'd have to jump to helping teams apply TDD on real projects. But that was overwhelming too.
You must go beyond TDD Katas. They only show you TDD at the Unit Test Level. You won't learn the bigger picture. You won't learn how to start with User Stories and Bugs. You won't learn how to apply TDD at the Acceptance and Component Test Levels.
Due to these limitations of TDD Katas, I decided to create a better way for Software Engineers to learn TDD - by building their TDD Sandbox Project.
Want to apply TDD in practice?
You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project. Access TDD in Legacy Code.
Katas are ok for learning basics, but don't prepare developers for real-world complexities.
https://www.figma.com/board/FCmGwRPIO8cLowDRraJhgr/Learning-TDD?fuid=994918187711519377
I think they are very useful, I think it can also be done progressively and this is an example of how I do it, and obviously at the end there is a pet project.