Coding katas/TDD examples from solidbook.io.
TDD is such an important technique, but it's one of the most challenging software design techniques to master. There's a lot of confusion, misdirection, and partial explanations. Many of us have tried TDD but gave up because it was too hard or felt like it took too much time. I believe that's a symptom of not fully grasping how TDD is to be used in the real world.
In Part III - Phronesis, we start over. We start from scratch. Specifically, we:
- Understand the nature of complexity and features
- Understand how to identify behavior in features
- Fix our understanding of object-oriented programming
- Understand the difference between core code and infrastructure code
- Understand how object-oriented architectures work
With this foundation, in Part IV - Test-Driven Development Basics, Part V - Object-Oriented Design (With Tests), and Part X - Advanced Test-Driven Development we continue with:
- Practicing the Classic TDD school of thought on many katas
- Practicing the Mockist TDD school of thought on many katas
At this point, you'll have an understanding of how and to what extent to use TDD in a variety of contexts (ie: the front-end, in the back-end, with E2E tests, as unit tests, and so on).
Finally, the path to master involves one step:
- Practice. And lots of it (hundreds).
Let's begin. Make sure you've read Part III - Phronesis first.
Classic TDD, created originally by Kent Beck, is also known as the Detroit/Chicago school of thought for TDD. What makes Classic TDD classic is the absence of mocking (found in the Mockist/London-style form of TDD). In Classic TDD, we verify our classes or functions by testing them exactly as they occur without mocking out dependencies. This means that if some class we wish to test relied on the use of a database, we'd be testing that class with the database connection as well. While this gives you a greater level of confidence that your code is working correctly, for code involving infrastructure code, it makes test setup and teardown harder (specifically with respect to unit tests) and it makes them run slower as well slower.
To start our TDD journey, we focus on mastering the Classic TDD school of thought. We are solely focused on solving problems that exclusively involve core code (no infrastructure).
29. Getting Started with Classic Test-Driven Development
30. Working Backwards using Arrange-Act-Assert
31. Avoiding Impasses with the Transformation Priority Premise
Coming soon