TDDBUDDY
Open source TDD training material.
Providing extensive industry based insights into the discipline of TDD.
Open source TDD training material.
Providing extensive industry based insights into the discipline of TDD.
TDDBUDDY is an open source project with a single goal: facilitate better industry adoption of the practice by providing richer insights into it.
A common perception in the software development industry is that learning TDD is mainly about Katas. That it is about finding a perfect progression through a Kata making a video of it and posting it online for everyone to see how much of an awesome programmer you are.
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 meaningful names for test using a BDD style format of FunctionName_Whenxxx_Shouldyyy, to clearly reveal intent.
Read more about scenario naming here
And to help you improve your naming check out the Stages of Naming. It offers concrete guidance on how to create more meaningful domain driven names.
With many years of practical TDD experience on production software we know the value of validated learning. There are many insights that only surface once faced with the challenge of doing TDD on a real code base.
TDD is an incredibility difficult discipline to do well. The foundational elements of TDD are relatively simple to learn, yet it takes many years of assembling the pieces on a variety of projects to do it well. The single biggest failure a practitioner of TDD can make is to not reflect upon
their code, with an intent to beautify it, after each Red-Green-Refactor cycle.
Just applying SOILD or DRY principle 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 revealing intent to the reader are critical elements to building a maintainable test suite that others want to utilize and contribute to long term.
One of our industry driven insights is TDD Gears.
TDD contains a Red-Green-Refactor cycle at its core with a collection of practices and principles. TDD gears is a
model to explain how it all fits together. There are three forward gears and one reverse gear in TDD because sometime you just need to back up and try a different approach.
Low gear is to get going and build context, medium gear is to enhance design and apply advanced patterns, high gear is used to build functionality by
following existing architectural patterns and practices of the system.
With reverse used to get back to green after a back refactor or to help take a new approach to find the next test.
To us TDD is not just about design, it is about code correctness. We use science based reasoning to understanding how the limitation of the human condition impact one’s ability to write clean and correct code.
According IMB System Sciences Institute, fixing a bug in production is 100x costlier then fixing it at design time.
And applying the practice to TDD reduces production bug density by 40%-80%!
Beyond the cost implications of not using TDD, there are cognitive implications developers will face when interrupted to help with fixing those nasty production bugs. It takes about 20 minutes to regain focus once an interruption occurs.
This means for every bug a developer is asked to attend to while working on other things results in 40 minutes of lost productivity 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 allow 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.
A collection of NuGet packages and seed projects to help you on your C# or JavaScript journey.
An open source DotNet NuGet package designed to facilitate fast integration testing when using Entity Framework with code first migrations. Check out the source on github
A seed project with karma and jasmine already configured. Great for getting started with a JavaScript kata.
A seed project with nunit, nsubstitute and nunit test runner already configured. Great for getting started with a C# kata.
Our catalog of katas is unique in that it contains a lot of lesser known katas. It also contains a bunch of katas we created to keep you challenged. We welcome you to attempt our katas in any language, we have done them in C# and JavaScript.
A simple kata involving 100 doors that are toggled with each pass through the doors. This is a good kata for those new to a language.
A simple kata to ensure a string contains balanced brackets.
A great kata for introducing Substitutes. It contains C# specific language.
An advanced Kata that will challenge you to find creative solutions to ensure good design and testability.
A simple kata involving the validation of IPv4 addresses.
A fun kata to find the last sunday of each month in a given year.
An intermediate kata to build a rover that moves around Mars. This was a great JavaScript kata. A follow-on action would be to build a UI using Angular or React on-top of the library.
A refactoring kata in C#. It was found on RedGate's website. A great kata to do as a mob.
An intermediate kata about converting numbers to words. E.g. 2400 is two thousand four hundred. It is a great kata for learning a new language.
An intermediate kata involving DB integration test or Substitutes. It contains C# specific references.
An intermediate kata about building a in-memory cache, think advanced dictionary.
An intermediate kata about parsing a URL into its parts. A great kata to do as a mob.
A simple kata about trimming whitespace at the end of a line. A great kata to do as a mob.
A refactoring kata. The code base is a WPF Calculator sample app.
An intermediate kata about building a time calculator to figure billable hours for a day.
A kata about an IoT device for the laundromat industry. It is very mocking focused.
A difficult kata about ranking and comparing poker hands.
A difficult kata about making a bingo game driven by user stories.
A kata about the classic game driven by users stories.
An intermediate kata making a calculator, with fluent syntax, that has add and subtract operations. Check out our solution on github.
A kata about implementing a contact-less travel card for subways.
A kata about building the fundamentals of a social network experience.
A kata classic TDD kata with a twist.
A kata about making short urls like https://goo.gl does.
A kata about creating a command line todo list application
A kata about greeting people. Starts off simple and increases in complexity.
A very simple kata about converting metric units to imperial units. A great kata to learn a new language with.
A kata about building custom robots. It is a more interesting take on the traditional shopping cart.
A kata about offering change for a purchase - think vending machine.
A collection of references and practices to build and grow your understanding of TDD.
The 3 laws of TDD, with an detailed explanation of the Red-Green-Refactor cycle.
How to run your own mob sessions to build a shared technical understanding for your team.
A list of 22 constraints to apply to any kata to up the difficultly.
The model consist of three forward gears and one reverse gear, because sometime you just need to try a different approach.
How to apply scenario style naming to meaningful name your test.
Naming is hard, this supplements is a useful for improving your naming of methods, variables and test names.