Test with confidence, code with clarity

Elevate your development game with TDD insights from a seasoned software engineer with over two decades of experience!

Exciting news! I am redesigning tddbuddy.com to create a fresh, user-friendly experience tailored to your TDD needs.
Stay tuned for more updates! For now check out the Road map to see what is planned.

More than just Katas

A common perception in the software development industry is that learning TDD is mainly about Katas. It's believed to be about finding a perfect progression through a Kata, making a video of it, and posting it online to showcase programming skills.

While Katas are critical for teaching the foundational elements of TDD, there are many other practices that contribute to a well-built and maintained test suite. One such practice is using meaningful names for tests in a BDD-style format of FunctionName_Whenxxx_Shouldyyy, which clearly reveals the intent of the test.
Read more about scenario naming here

To help improve your naming, check out the Stages of Naming. It offers concrete guidance on how to create more meaningful domain-driven names.

Industry Driven Insights

With many years of practical TDD experience on production software, we understand the value of validated learning. There are many insights that only surface once faced with the challenge of doing TDD on a real codebase.

TDD is an incredibly difficult discipline to do well. Although the foundational elements of TDD are relatively simple to learn, it takes years of experience on a variety of projects to master them. The single biggest mistake a TDD practitioner can make is to not reflect upon their code with the intent to improve it after each Red-Green-Refactor cycle.

Simply applying SOLID or DRY principles will not serve a test suite in the long run. Ensuring tests remain well-named using domain concepts, compact, and read like a small story that reveals intent to the reader are critical elements of building a maintainable test suite that others want to utilize and contribute to in the long term.

TDD Gears

One of our industry-driven insights is TDD Gears. TDD contains a Red-Green-Refactor cycle at its core, along with a collection of practices and principles. TDD Gears is a model that explains how it all fits together. There are three forward gears and one reverse gear in TDD, as sometimes you need to back up and try a different approach.

The low gear is used to get started and build context, the medium gear is used to enhance design and apply advanced patterns, and the high gear is used to build functionality by following existing architectural patterns and practices of the system. Reverse gear is used to get back to green after a back refactor or to help take a new approach to find the next test.


Science Based Reasoning

To us, TDD is not just about design; it's about code correctness. We use science-based reasoning to understand how the limitations of the human condition impact one's ability to write clean and correct code.

According to the IBM System Sciences Institute, fixing a bug in production is 100 times costlier than fixing it at design time.
And applying the practice of TDD reduces production bug density by 40%-80%!

Beyond the cost implications of not using TDD, there are cognitive implications that developers will face when interrupted to help fix those nasty production bugs. It takes about 20 minutes to regain focus once an interruption occurs.

This means that for every bug a developer is asked to attend to while working on other things, 40 minutes of productivity are lost for every bug fix interruption. The developer will spend 20 minutes building context to solve the bug and another 20 minutes building context to get back into what they were doing before the interruption.

Unfortunately, interruptions are a fact of life. Using memory off-loading techniques like TDD allows a developer to regain focus much quicker because they carry a smaller memory load. Not using TDD forces the developer to carry all aspects of the work in their head, thus incurring a large memory load which results in the biggest possible disruption.