Testing, Testing. Developing, Developing: Discovering Test Driven Development
Back in 2003, Kent Beck and David Astels first proposed the concept of Test Driven Development, or 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. The developer(s) begin with a simple test requirement, and revise the code until the test is successful. Then the developer(s) create the next test, develop the associated code, and continue the cycle. And as it goes forward, the developer(s) “refactor”, or 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 applications code and the test scripts in parallel.
Lots of development goin’ 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 correctly, 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 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. 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 in 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 yourselves that you can develop documentation and code easier and more quickly. Moreover, you’re more likely to have a successful project and happy client to boot!
Have you instituted TDD in your company? Let us know how it’s working for you. Click here [link to feedback]
To find out more about Test Driven Development, see http://agiledata.org/essays/tdd.html
To find out more about Avanceon’s development methodologies, click here.
Image Source: Freepik