Back in 2003, Kent Beck and David Astels first proposed the concept of test-driven development (TDD) as a new approach to develop project code. Simply explained, the concept postulates that for each step in development, only enough application code should be created to successfully complete a given test requirement. Developers begin with a simple test requirement and revise the code until the test is successful. Then they create the next test, develop the associated code and continue the cycle. As the process moves forward, the developers “refactor” (retest) the code to ensure nothing broke while new tests were incorporated into the application requirements.
This all sounds good, but how do we leverage this concept for automation applications?
Typically, we’re tasked with defining the requirements for a system as a separate documentation effort from test protocol development. This, in turn, is separate from the actual code development. In short, this means we might develop requirements and then develop the application code and the test scripts in parallel.
Lots of development going on here—but many projects can’t support the cost and time required for such an effort.
By looking at a test design prior to any code development, we eliminate the separate task of creating requirements for our code. More precisely, we incorporate requirements development into the test protocols, minimizing or eliminating the unique phase of creating a specification.
Simply put, you 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. You test the code and modify it until it passes the test, then move onto the next required test.
The reality is you will likely have many tests defined prior to writing your first bit of code, but you could write and test one at a time. Some of this becomes redundant, especially if you have a library of proven, quality code from which you can draw. 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 a short time, with sufficient documentation to develop and test and verify that the application is sound. Many clients have little or no specifications 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. You can also use it to define and test hardware implementation and unit and system architectures. In the end, your test document and requirements specification are one and the same and complete before any code is developed, hardware purchased or field work executed.
I suggest you try this on a small project first and verify for yourself that you can develop documentation and code easier and quicker. You’re more likely to have a successful project and happy client to boot!
Duane Grob is a principal engineer at Avanceon, a certified member of the Control System Integrators Association (CSIA). For more information about Avanceon, visit its profile on the Industrial Automation Exchange.
