Our software is always in a constant state of improving and growing. For the dev team this means that there are now more people working on more code than ever before and that our development process has to become more refined. When adding a new feature, we have to ensure the feature is robust, but also that the the feature has no unintended side effects.
One of the ways we are, as developers, keeping our ever evolving code base healthy and stable is through a process called “Test-driven development” (TDD). In a nutshell, as developers, we receive feature requirements, we then proceed to write tests for every requirement before the code is ever written.
Of course TDD initially produces useless results as every test will fail since the code has not been written yet. We then begin to write code that allows the tests to pass. From there we refactor (reorganize) the code in a proper structure that integrates with our current code base. The final result is code that can successfully execute every use case.
Seems almost redundant doesn’t it? I mean of course we should write code that does what the requirements demand of it, that’s what software companies do. The problems arise when requirements change or there are side effects. If a new feature has a side effect and you have to fix other parts of the code base to accommodate, you effectively cause ripples of instability within the system as each change you make can have unknown consequences.
With TDD, every use case has a test, every test must pass. If the use case changes, the tests change.TDD also drives design, many times when designing a feature, it looks great on paper but when you sit down to code it, it just does not work. With TDD, the design grows organically from the tests in a very top-down manner.
In summary, test-driven development is a process our development team is embracing to ensure that our software can continue to grow and improve while keeping it rock solid.
Image source: http://www.perforce.com/blog/130315/test-driven-development