In this series, I will be discussing Test Driven Development. Since there are many different types of testing, I will be focusing on the following two forms:
- Verification Testing: Testing to determine whether a developed software feature meets its requirements, and
- Unit Testing: Testing of individual units of code (i.e., classes, methods, etc.) to determine whether they function correctly
The Traditional Approach
A traditional approach to software design might look like this:
We start with requirements definition, move on to design and implementation, progress to unit testing and verification testing, and once testing has passed, accept the completed software. This can be done either in a waterfall approach, where each step is completed for the product as a whole before moving on, or in an agile approach, where this cycle is shorter and completed one feature at a time.
Test Driven Development (TDD)
Test Driven Development (TDD) is different in that we aim to write the tests as early as possible in the process. A typical TDD approach might look like this:
We start with requirements definitions as before, but now we write the tests as early as possible based on these requirements. The main focus of this “Write Verification Test” step is generation of functional test plans (possibly hardware-in-the-loop) that can be used for verification testing in order to demonstrate that the feature being developed meets its requirements. This is typically referred to as Acceptance Test Driven Development (ATTD). As a side note, after drafting the test, we can run it, ensuring that it fails so that we know we have a good test. Writing unit tests can also be done as early as possible, but this step typically follows design as we need to understand the software units we will be testing. This is sometimes called Unit Test Driven Development (UTDD).
After completing the functional test plan, we then design and implement the software, and run the tests again. Once they pass, the feature is completed. Test Driven Development tends to work best when used during agile development processes. As a side note, both of these diagrams demonstrate idealized approaches. More realistically, we often loop back to earlier steps. In the traditional approach, we’ll discover bugs or design flaws during testing that force us to revisit the design or implementation steps. Similarly, during TDD we do not often write the perfect test on the first pass and may need to revisit it during design or implementation.
So, to summarize
Test Driven Development is a unique approach to software process where tests are written as early as possible in the development cycle. Verification test, used to determine whether software meets its requirements, can be written prior to the software design step. Unit test, used to determine whether individual software units are functioning as expected, are written after design, but before the code is implemented. In Part 2 of this series, I will share some of my positive prior experiences with TDD and explain why adopting this process may help your project. In Part 3, I will take a closer look at some of the reasons TDD may not work for your project and suggest some critical questions to ask before deciding.
At Syncro Medical, we work with our clients to identify the overall development and testing methods that are compatible with their internal process and that best meet their development objectives.
Comments are closed.
