ESC 2012 Boston Part 2 - test-driven development

-October 09, 2012

The 2012 Embedded Systems Conference (East) in Boston was a great success this year. There were a number of great themes this year ranging from the internet of things to agile development techniques. The topic that I found most intriguing at this year’s conference was Test Driven Development or TDD. I had the opportunity to sit in on a full day training course on TDD taught by James Grenning, the author of “Test-Driven Development for Embedded C”.

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:
  1. Add a small test
  2. Run all the tests and see the new one fail, maybe not even compile
  3. Make the small changes needed to pass the test
  4. Run all the tests and see the new one pass
  5. Refactor to remove duplication and improve expressiveness
One of the advantages of TDD is that as a product progresses and changes to the code base are made, the tests developed as the software is written act as a regression test suite. All tests that are written are run every time the code is compiled. If a change to the code breaks something in a module that was written 3 months ago, as soon as the test is ran the developer becomes aware of the bug. This removes bug hunting near the end of the development cycle and instead reveals the bug the moment it is created. This has the opportunity to save not only time but also major headaches when the pressure is on to get the system out the door.

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.

Loading comments...

Write a Comment

To comment please Log In