Testing, Testing. Developing, Developing. Discover Test-Driven Development

April 29, 2019
Develop document and code for an automation project easier and quicker with a method that develops a little, tests it, then develops some more.

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.

Sponsored Recommendations

MSD-SLC16G

CLICK industrial memory card, 16GB microSD. For use with all products with microSD memory card slot.

C0-12DRE-D

CLICK Ethernet Analog PLC, 24 VDC required, Ethernet and serial ports, Discrete Input: 4-point, DC, Analog Input: 2-channel, current/voltage, Discrete Output: 4-point, relay, ...

C2-FILL

CLICK PLUS option slot cover.

USB-CBL-AMICB6

AutomationDirect programming cable, USB A to microB-USB, 6ft cable length. For use with Productivity1000 and Productivity2000 CPUs and most USB devices.