Testing
Using TDD to Influence Design
Test-Driven Development, or TDD for short, is a tool, a mindset and a process which aids in the development of robust, SOLID-based, scalable code. It fosters a shift towards an implementation-agnostic codebase.
It is a tool that helps you work smart, by writing just enough code to make a test pass; a process that enables you to add value through the new features that you build, making sure that they won’t break the rest of your code; and a mindset that embodies ownership of your codebase through and through.
The base of TDD is the Red-Green-Refactor cycle:
You write the test, run it and it fails (Red)
You write just enough code to make it pass (Green)
You improve the code (Refactor)
The idea behind it is that you build the functionality quickly and without risking the stability of the remaining codebase, and - once the test passes - you can refactor.
It is worth mentioning, however, that the purpose of TDD is not to increase test coverage - as with all things agile, quality wins over quantity. It is also not a single testing suite, used in a specific phase leading up to development: rather, it is production code.
While we do, in essence, “gain” our unit test suite “for free”, the advantages of TDD extend far beyond code scalability: starting every functionality with a test leads to simplified interfaces and design, which is much more user-friendly and accessible by nature - not to mention, it makes it easier to implement and test for a range of accessibility features, which brings our product closer to a wider range of users.
Want to know more? Start with the links below:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
