Test driven development (TDD) is potentially useful for automation applications by eliminating the separate task of creating requirements and specifications by incorporating requirements into the test protocols.
Test driven development (TDD) was first used in 2003 as a new approach to develop project code. The concept postulates that for each step in development, only enough application code should be created to successfully complete a given test requirement. The developers begin with a simple test requirement and revise the code until the test is successful. Then the developers create the next test, develop the associated code, and continue the cycle. And as it goes forward, the developers retest the code to ensure nothing broke while new tests were incorporated into the application requirements.
This all sounds good, but how do developers leverage this concept for automation applications?
Typically, developers are tasked with defining the requirements for a system as a separate documentation effort from test protocol development. This is separate from the actual code development and means we might develop requirements and then develop the applications code and the test scripts in parallel.
That’s a lot of development, but the problem is many projects can’t support the cost and time required for such an effort.
Looking at a test design prior to any code development eliminates the separate task of creating requirements for the code. More correctly, we incorporate requirements development into the test protocols, minimizing or eliminating the unique phase of creating a specification.
Simply put, the developer define the requirements of the application by specifying the test that will verify the requirement is satisfied correctly… then write the code for that test. The code is tested and modified it until it passes the test, then move onto the next required test.
The reality is developers will likely have many tests defined prior to writing the first bit of code, but they could write and test one at a time. Some of this becomes redundant, especially if the developer has a library of proven, quality code to draw from. It’s just more efficient to test when you have only written a few lines of code rather than after you’ve written several hundred (or thousands) of lines.
The objective here is to develop clean code that meets the test protocols in short time, with sufficient documentation to develop and test and verify the application is sound. Many clients have little or no specification or requirements and prefer to not purchase design documents. We have all seen projects where the expected results are “obvious” or “easy” and only require a few hours of dialog with the owner/end user in order to proceed. However, we always need a way to test and verify with the client that what we have developed is, indeed, what they want.
The other advantage of TDD is it can apply to more than just code development. Developers can also use it to define and test hardware implementation and unit and system architectures. In the end, the test document and requirements specification are one in the same and complete before any code is developed, hardware purchased, or field work executed.
It’s good to try TDD on a small project first so the developer can verify they can develop documentation and code easier and more quickly.
Duane Grob is principle engineer at Avanceon, a CFE Media content partner. This article originally appeared on Avanceon’s website. Edited by Chris Vavra, production editor, Control Engineering, CFE Media, [email protected].
