Small Changes by Means of Test-Driven Development

Let’s start with a picture by Kent Beck (source: https://tidyfirst.substack.com/p/canon-tdd):

Examining this good practice in developing features in a product, we can notice that it is all about small changes—no large change is acceptable. By applying patterns to grow a feature one small piece at a time, product engineers significantly reduce the intrinsic cognitive load on reasoning and decision-making as small changes mean having less or even no complexity to take into account. At the same time, when things go wrong, there is also a very limited amount of change to investigate, again reducing cognitive load.

TDD (test-driven development) is, in fact, more of a requirements discovery tool than anything else. See: https://youtu.be/I62FdDk3UKk. This doesn’t mean we don’t recognize the quality aspect of applying TDD! Writing tests first ensures that each piece of code is tested as it is written, which can significantly reduce the likelihood of defects making it into final production, thus avoiding further context switching. Applying TDD naturally leads to more modular, flexible code and de-coupled architectures that are easier to maintain and extend. Plus, the behavior tests become the living (or executable) documentation of the code.

On top of it all, TDD facilitates refactoring in such a way that it becomes a less risky and integral part of the development process, keeping things relevant, readable and easy to change. Developers can make changes to the system, add features, and refactor code without the fear of unknowingly introducing bugs. The comprehensive test suite built using TDD acts as a safety net that can catch errors and unintended consequences of code modifications, leading to greater confidence among developers. This significantly lowers cognitive load for all involved.