5 reasons to build your TDD Sandbox Project
TDD is too hard to apply in Real Life Projects. Here are 5 reasons why you should build your TDD Sandbox Project first, before applying to your Legacy Project.
👋 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 too simple. Real Life Projects are too hard. Sandbox Projects are the “sweet spot“ for your learning journey. You should start with a Sandbox Project to practice your skills, and then apply what you’ve learnt to your Real Life Project.
Here are 5 reasons why you should build a TDD Sandbox Project first, before applying TDD to Real Life projects.
1. Katas are too simple
Many TDD books, courses and trainings rely on TDD Katas. The problem is that Katas tend to focus on how to apply TDD to isolated classes to solve algorithmic problems (e.g. FizzBuzz kata), but don’t handle challenges of real life systems - working with dependencies, external systems, databases, and multiple levels of tests.
Why TDD Sandbox Project? Sandbox Projects are a much more realistic simulation of Real Life Projects, hence it’s easier to transfer skills from a Sandbox Project rather than a Kata.
2. Real Life Projects are too overwhelming
Real Life Projects already have high domain complexity and technical challenges (e.g. untestable architecture). It’s sometimes too much for our brains to handle both of those simultaneously. Teams may get stuck with toolchain setup (e.g. Docker, Testcontainers, WireMock, Pact, PIT). They may not even know the different test types or how to write them, and find progress to be frustrating and slow, when jumping into TDD in a Real Life Project.
Why TDD Sandbox Project? Sandbox Projects are realistic simulations of Real-Life Projects but without the full complexity of real-life projects. They help developers focus on the technical complexity of learning automated testing and TDD without the full domain complexity.
3. Team alignment & developer onboarding
Multiple teams are working directly on their own Real Life Project. If one team learns TDD and applies it to their Real Life Project, they then have to explain both the business domain and the technical practices (e.g. automated test types and TDD practice). Similarly, when onboarding new developers, the new developers have to learn domain logic and TDD both at once. The learning curve is too steep.
Why TDD Sandbox Project? Sandbox Projects provide a shared learning space for teams, so that they can centralize their technical practices in the Sandbox Project, without bogging it down with domain-specific knowledge. It also helps us show the end state, to help counter resistance to TDD before applying it. It can enable us to standardize practices, share knowledge across teams, and also simplifies onboarding.
4. De-risk learning & experimentation
If you jump to applying TDD on Real Life Projects, you face risks. When introducing Unit Testing, we need to break dependencies, and can introduce unnoticed regression bugs. Refactoring without an adequate test suite is also risky, leading to production bugs. Furthermore, learning new practices results in delivery slowdown, which can cause deadline stress and pressure from business. When any of these negative experiences happens, the team can then blame it on TDD.
Why TDD Sandbox Project? Within a Sandbox Project, we can learn new practices without the fear and stress of breaking Production. It’s ok to make mistakes, and to learn from your mistakes in a safe environment without risks.
5. Becoming a Change Leader
Adopting TDD requires someone to initiate and lead the change, esp. in cases where the company has no experience in TDD. Before becoming a TDD advocate, you first need to become competent before sharing it with others. If you try to introduce TDD but haven’t mastered it, you’re risking poor implementation, reputation loss and your team to be against TDD. Most likely you also need alignment from your team and management.
Why TDD Sandbox project? A TDD Sandbox Project enables you to get practice and become proficient at TDD, before introducing it to your Real Life Project. You can share it with your team and management, to get team alignment by seeing the end result. This makes it easier to spread TDD practices.
Transitioning from Sandbox to Real Life Project
Once you’ve gained practice in your TDD Sandbox Project, you can showcase it to your team, to gain alignment, and compare it with your existing non-TDD Real Life Project. Then we can repeat the same TDD transformation process that we already applied to the TDD Sandbox Project, but now apply it to the Real Life Project. Along the way, we also need to have the right coaching skillset to help transition the team. We can further expand this across teams.
Of course, the transition from Sandbox to Real Life Project will have its own complexities, such as change management and the need to handle resistance, to ensure alignment and motivation. So that might be a subject for some future articles.
Start your TDD Sandbox Project
Pilots practice on Flight Simulators, before they fly a real airplane. Doctors practice on Medical Training Dolls before practicing on real people. We learn to drive a car by practicing in the parking lot before we go on the road.
Similarly, we should practice TDD on a Sandbox Project before applying it to a Real Life Project. That’s exactly what I discovered during my work as a Technical Coach. That’s why I’ve distilled what I learnt based on Real Life Projects, and wrote it up as a series of step-by-step guides so that you can build your own Sandbox Project, showcase it to your team, and then apply the same process on the Real Life Project.
Sandbox Projects have a high level of realism, so it's much more practical to apply what you've learnt at work.