Test-Driven Development: Always in style
Table of contents
The Singudinum University in Belgrade hosted the Tarabica Conference on the 5th of April. Professional developers from all across Serbia converged to learn from the Microsoft experts lecturing during the conference.
Our CTO, Senior Software Architect and development guru Boban Miksin attended the conference to give a lecture regarding the application of Test-Driven Development (TDD).
As important as being secure in your knowledge of programming languages and solutions, understanding how to construct or improve upon existing structures with simple designs that prove clarity and inspire confidence is extremely important.
We asked Boban to answer a few questions that would succinctly inform the general public about the conference and his lecture on Test Driven Development.
What is TDD?
TDD stands for Test-Driven Development. It is a software development discipline based on a red-green-refactor principle, where a developer writes an automated test, designed to fail, that defines the desired new function or improvement being developed. Then the developer writes the minimal code needed to pass the test, and refactors a test-positive solution that satisfies industry standards and makes it easily extendable and maintainable.
More info on TDD can be found here: http://en.wikipedia.org/wiki/Test-driven_development.
Why use TDD?
TDD is a great practice because it encourages developers to write only the most necessary code…and code that won't contradict previous implementations. It also teaches developers to simplify and organize their code in a way that their team will not have any problems understanding it. By practicing TDD, developers write code incrementally, conscientiously and deliberately covering every aspect of the functional specification.
Is there a best time to use TDD?
It is always better to apply TDD from the outset on a new project. Writing tests for already established code is not TDD practice per se. As powerful as TDD is, it can also lead to unexpected results when applied by inexperienced developers, and it inadvisable for someone new to unit-testing to apply these methods to a live project. TDD, like any other discipline, requires time and practice in order to master it.
How to learn TDD, and how to use so it works for you:
TDD is act of discipline, not a programming language, so we cannot apply the same methodologies toward learning it. You cannot master it through reading, discussion, or studying other people's code. In order to really understand it and be able to use it, a developer has to practice. My recipe is 30x30: 30 minutes every day for 30 consecutive days. That is enough time to learn the discipline, and to be able to apply it to a live project.
In regards to what one would do in those 30 minutes, I suggest practicing the "TDD katas." In martial arts, karate in particular, the kata are choreographed movements, performed without an opponent. Through practice, the movements are perfected. Every movement has its purpose, and only through strenuous practice can it be understood and mastered.
Back to the 30x30 recipe- a developer should pick the simplest TDD kata and solve it, then repeat the act of solving the same problem again and again until the solution is produced easily and confidently - and then they should proceed to the next one. In this manner, developers can prepare themselves to apply TDD to new or already live projects.
