Software development is a very demanding task, in which fault occurs frequently. In the traditional development approaches, most errors will be found during build stage. These approaches lead to this kind of problem being detected in a later stage, often when the app is being used by the end user. This is the context for Test Driven Development (TDD). The TDD is a software development technique, often associated to agile methods. This technique consists of small development iterations, where the test case, that covers an app feature, is written before the same feature is deployed.
TDD tries to solve above mentioned problems, focusing on tests and reversing the way of development. The software development process accordingly to TDD, also known as Red/Green/Refactor cycle, stands for the repeating running of the following steps: to write a unitary test that fails before writing any functional code (Red); to write a functional code until the unitary test is approved (Green); in the end, if necessary, to restructure the code, removing redundancies and improving its structure, assuring that all unitary tests keep on being successful (Refactor).
TDD also recommends the test automation, so the code is always built and run as part of build’s regular process. Thus, assuring that the addiction of a new feature or the restructuring of code doesn’t brake features already deployed.
The approach suggested by TDD makes the developer to focus first in the expected end result and only afterwards in solutions to achieve it, making the solution design more simple and pragmatic. TDD usage reduces the quantity of bugs, improving the product’s quality. The end app becomes more solid, since its assured that the code, for which tests were deployed, works. Comparing with traditional approaches, in which the code is only tested a lot of time after its deployment, time needed for maintenance of the app, resulting from error solving tasks, is less.
TDD provides code deployment in a more flexible and modular way, promoting also development through layers. It makes the developer to think in small chunks of code that might be tested isolated and independently. As a result of the code restructuring, it becomes easier to deploy. This increases safety, since the restructuring won’t break the code that worked until then. The quantity of functional code is also, usually, less than the quantity of code from traditional approaches.
One of the main obstacles is the reluctance that some developers initially show to adopt this technique, stating that they have to write more code than usual and that test deployment is a waste of time. The learning curve is somewhat long, what may contribute also to that argument. For programming languages without a unitary test’s framework to deploy TDD might become an hard task.
It is also difficult to deploy when software was developed using legacy programming languages or when doesn’t exist a support documentation for much older apps. Frequently, the developer that will make the changes does not know what the code actually do, thus fearing naturally that changing a chunk of code in a certain location might have repercussions somewhere else.
TDD usage advantages overcome strongly its disadvantages. The fact that it is necessary to deploy more code than in traditional approaches is not enough to overcome the benefits of obtaining an end product with less bugs and shorter maintenance periods. TDD is not certainly the solution to all problems. However, it helps developers to enhance programming, delivering mode trustful, modular, flexible and easy to maintain solutions that meet the Client’s requirements.