Test-driven development, commonly called TDD, is a practice used by software developers as a means of producing trouble-free code in the fastest time possible. At its simplest level, TDD has four primary elements.
-
The programmer devises a test that will fail on the initial run and writes the code for the test.
-
The test is performed to ensure that it fails, thus proving that the test will not provide a false "pass."
-
The programmer writes just enough code — often less than 10 lines — to pass the test.
-
If the code passes, the programmer cleans up the code to formalize it, then moves on and repeats the test-fail-code cycle for the next requirement. If the code fails, the developer debugs the code and runs the test again, repeating until the code passes the test.
Benefits of TDD
TDD is especially popular with developers who favor the agile method, such as delaPlex. The agile method divides a project into a series of small steps that can be completed quickly and independently. This allows changes in scope, priorities or functionality to be made quickly; with traditional methods, such changes can require costly and time-consuming adjustments as progress is scheduled in a linear fashion. TDD, therefore, is a good fit with the agile method as it allows developers to test and debug the code for each "mini-project" quickly.
Another benefit of TDD is that the programmer cannot write a failing test without having a clear understanding what the actual program is supposed to do. TDD forces developers to examine requirements and specifications more closely before they start writing code. This helps refine specifications in the early stages to prevent delays or miscues later in the cycle. The additional thought given to the requirements also helps developers write code that is cleaner and more concise.
How TDD Speeds Delivery
Those who do not fully understand how TDD works often fail to see how TDD can speed turnaround time. They believe that writing so many individual tests will slow down the process. This is not the case. The tests consist of just enough code to fail, so they do not require an inordinate amount of time to write. Code can often be reused, speeding the process even more. In addition, the tests become part of the program documentation, making it easier for those who must maintain the program in the future.
One of the biggest savings in time, however, can come at the end of the project. With traditional development methods, testing and debugging occurs at the end of the project. By that point, there may be tens of thousands of lines of code that must be examined to find the problem. Furthermore, programmers may have written the code weeks or even months earlier and have "memory gaps" as to why they included a particular line or just what they might have changed. Debugging can take an inordinate amount of time; fixing one issue can cause a failure when the program reaches a different point in its execution. With TDD, the program has been written with the "debug as you go" method, so by the end, there should be little or no need for an overall debugging.
Another myth about TDD involves the length of time required to run a complete series of tests. It is true that at some point, developers will likely run multiple tests on the production code that require many hours to complete. However, the majority of the tests are run on independent functions or small modules, so they execute quickly, typically in one to five minutes.
TDD can be combined with acceptance testing to help ensure that the product the client receives satisfies the functional requirements. Acceptance test-driven development, or ATDD, involves writing a single behavioral specification or acceptance test and the minimum functionality or production code to conduct the test. ATDD provides an executable, detailed design specification just when it is needed.
Although TDD is commonly used for new development, it is also an ideal process for updating or maintaining legacy systems. A particularly robust legacy system may contain hundreds of thousands of line of code and little documentation. TDD allows every change to be tested separately to prevent cascading failures.
TDD excels at providing validation and detailed specifications. On the other hand, agile model-driven development, or AMDD, is often better for "big picture" issues, such as how people will actually use the software or what the overall design should be. Fortunately, TDD and AMDD work extremely well together, allowing a project to go from initial concept to completion in less time.
When TDD is Insufficient
Despite the advantages of TDD, there are certain scenarios in which TDD cannot perform sufficient testing to ensure reliability.
-
TDD requires automated tests. This means that any aspect that requires a user to interact with the program, such as a user interface, cannot be properly tested using TDD.
-
Some networks are configured in a manner that prevents the test from making the needed connections. This can be a problem when attempting to test integration.
-
TDD can be challenging if the testing procedure will alter "live" data. There are ways around the issue, such as establishing a "revert" point and automatically rolling back the data to its pre-test state or using "mock" data for testing. However, it is not always possible to fully test a function's integration with existing data.
-
TDD is not ideal for modelling database design. Although the TDD philosophy can be applied to databases, tools are currently lacking for the effort.
-
For a TDD project to work, everyone involved must take a TDD approach. This means that every programmer must agree at the project's start to utilize TDD throughout the development cycle, but it also means that management must understand the concept and support TDD as well.
TDD does not write your specifications for you. Nor is it the only testing that is needed for a project. However, it helps refine specifications, ensures cleaner code, improves documentation and allows faster turnaround on projects. Given the many advantages of TDD, it makes sense to choose TDD whenever possible.
If you would like to learn more about agile development and TDD, contact the experts at delaPlex. We are a different type of SDaaS (Software-Development-as-a-Service) provider offering dedicated teams, 24/7 support and a large staff of programmers who have expertise in all of the latest technologies.
