ESC 2012 Boston Part 2 - test-driven development
One of the many discoveries of the day was that TDD requires a paradigm shift in thinking about how software is written, the result of which has the potential to revolutionize the way embedded software is written forever. The way in which a software developer typically writes software involves sitting down and writing a bunch of production code to perform a particular function.
Once this code is written, the developer attempts to compile the code, which usually fails, resolve any compiler issues and then run the code. The result is often the discovery that the code does not perform as intended. Even if the developer successfully passes the tests they are usually a couple of high level test cases, which leads the developer to say a prayer and then through a leap of faith commit the production code as completed.
At a later stage of the development cycle, a bug undoubtedly is discovered that could have just been written or it could have been written three months ago. The reality is that the few test cases that are performed on the system only cover a few basic cases and the system at some point in the future will require debugging that could take days, weeks or possibly even months to debug.
This is where Test-Driven Development comes onto the scene. Test-Driven Development can be simply defined as “a technique for building software incrementally”. The concept behind the technique is to develop small pieces of code that are tested and proven to work and then build upon them by additional small pieces of code that are tested. By doing this the bugs should become apparent immediately instead of three months later when the system goes into system integration testing.
The basic steps of Test-Driven Development were defined in Kent Beck’ book “Test-Driven Development”. The general process is outlined below:
- Add a small test
- Run all the tests and see the new one fail, maybe not even compile
- Make the small changes needed to pass the test
- Run all the tests and see the new one pass
- Refactor to remove duplication and improve expressiveness
Test Driven Development is definitely a different way to look at software development. Rather than writing code and then debugging later, TDD forces the developer to think first about a test case and then only write the code that makes the test case pass. Then the process is repeated. At first this not only looks but also feels counter-intuitive; however, once a developer starts to get more familiar with the process the advantages become apparent and the speed at which software is developed greatly improves.
For additional information on Test Driven Development I highly recommend investing in “Test-Driven Development for Embedded C” by James Grenning. The book is not only an easy read but will allow you to take your software development skills to the next level, allowing you to develop code that is not only more robust but also decreases the severity of bug hunting headaches.