While most developers have heard of test-driven development, some developers don’t understand how to implement this development methodology or what benefits it can provide. When employed properly, test-driven development can be a very effective strategy for developing high-quality code and ensuring good test coverage in an agile environment.
Below, I will define test-driven development and delve into the reasons for the continuing relevance of this particular development strategy. In addition, I will discuss the benefits of test-driven development in constructing an effective test automation strategy.
What is Test-Driven Development
One manner in which to define test-driven development (popularly shortened to TDD) is to explain the steps that must be taken in order to put it into practice. TDD begins with the developer identifying a specific function that fulfills the requirements for the particular feature on which they are working. The developer must then write a failing test for the piece of code, as the functionality does not yet exist.
Next, the developer writes the code to lead to a successful run of this test. They can do so with no regard for code efficiency or best practices. The goal is to simply turn the failing test into a passing test without disrupting any additional tests that exist in the test set. Upon achieving a successful run of the test, it’s time to refactor, increasing readability of the code and reducing complexity. The developer fine-tunes their newly developed function for efficiency and style, all the while ensuring that the success rate for the test set’s execution remains at 100%.
The Benefits of TDD in DevOps: Relevance Moving Forward
Test-driven development has been around for awhile. It is seen as being both tedious and time-consuming for the developer. While this may be the case during an organization’s initial adoption of the strategy, it doesn’t remain so as experience is gained.
Developers are creatures of skill. As they become more familiar with the techniques and technologies that drive TDD they will inevitably begin to develop high-quality code at a faster rate. But that is hardly the only reason for the time investment that is required to get started with the practice.
Below we will discuss why TDD is beneficial years after its origination as organizations move towards DevOps.
DevOps and Test-Driven Development
DevOps can be described as the elimination of the silos that slow the progression of application changes through the development pipeline and into production. Think: faster development cycles. But these faster cycles can’t come at the expense of code quality. This is where TDD comes into play. With the arrival of DevOps and the culture change that came with it, the benefits of TDD were amplified.
The need for shifting testing to the left – i.e., earlier – in the development pipeline, quickly became critical in the effort to ensure code quality in shorter development cycles. And one of the major benefits of test-driven development is exactly that – testing is “shifted to the left” as it is baked into the development process rather than simply accounted for at later stages in the pipeline. With TDD implementing shift-left testing, three distinct advantages come to mind:
- Developers can modify and enhance existing features within a codebase with higher confidence that the changes being made pose less danger to the existing code. Due to the very fact that simple and repeatable tests are being written to drive functionality for each unit of code, the developer can quickly identify any functionality broken during refactoring upon execution of the test set. Any failing tests will swiftly direct the developer to the broken code, all before progressing beyond development.
- Bugs are much less expensive to fix in early development than they are in the later stages of the development lifecycle and in production. And when enforced properly, the rules of TDD do not allow development to progress if tests are in a failing state. As a result, the horrible show-stopping, schedule-threatening bugs will rarely, if ever, find their way out of development.
- TDD can help to drive behavior-driven development, or BDD. As described in this post by Ashley Hunsberger, TDD serves to provide feedback from the code while BDD does the same at the feature level. It is this combination that helps to save time later in the process taking a test-first approach to eliminate the potential fallout from a feature not functioning as desired.
TDD and a Test Automation Strategy
A crucial part of DevOps and the agile development methodology is the use of automated testing throughout the development pipelinewith the end goal being the development of test sets that provide a high level of test coverage thus ensuring a high level of code quality within the application. Test-driven development inherently contributes to excellent test coverage at the unit level.
Through TDD, almost every unit of code has tests written to validate its functionality. With each instance of new development, new tests are written to ensure that test coverage remains, for the large part, complete. This test set can then be run wherever the organization sees fit. By definition of TDD it will be run as developers write code but it can also be integrated within the organization’s build process to add yet another checkpoint for code quality. In this way, TDD can become a big contributor to an organization’s continuous testing practices, allowing for validation of functionality at multiple instances in the pipeline.
Conclusion
Test-driven development has remained relevant for a long time in an ever-changing software testing climate, and the benefits of this strategy now appear more relevant than ever. This is due, in part, to the emergence of DevOps and agile development techniques that value a high-level of test coverage with testing implemented as early as possible in the development process. In doing so, TDD results in the early identification of software bugs, thus helping to improve software quality while maintaining speed of delivery.
