I held the third monthly meeting of "Test Driven Development for Embedded C" reading group in Tokyo.
We read following two chapters then.
- The fifth chapter "Embedded TDD Strategy"
- This chapters introduces "Dual Target Testing" which is important to do TDD for embedded software development
- The sixth chapter "Year, but..."
- This chapter introduces opposing views for adopting TDD and answers for them
Concurrent development software and hardware makes embedded system development difficult
Concurrent development of software and hardware is common in embedded system development. As I told in the entry "Is TDD one of the solutions for difficulty of concurrent development of software and hardware?", concurrent development is one of difficulties in embedded system development. Bug whose cause are difficult to find often occurs because we move ahead while software and hardware are low quality.
I give you an example of concurrent development. I often develop embedded software as follows.
- I divide development period into several iterations.
- Each iteration has function scope.
- At the end of the iteration, we integrate software and hardware to make prototype. We evaluate it.
- I continue prototyping and create spec incrementally.
In this kind of prototyping, we have difficulties as follows.
- I don't have hardware at the beginning.
- I usually use minimum hardware to check booting OS.
- I also start from checking operation with previous product
This work is not productive. To realize productive embedded system development, software engineers have to spend enormous effort boosting software quality before hardware is ready.
Boost quality of embedded software early with Dual Target Testing
What can we do to boost quality of embedded software before hardware is ready ? James Grenning, the author of Test-Driven Development for Embedded C, recommend Dual Target Testing. This is a technique to make test with both of target hardware and PC possible at the beginning.
Here are key points.
- We build high quality software with exhaustive unit test and refactoring on PC from the beginning. Then we move to unit test with eval hardware.
- This work reduce unproductive work like finding logical mistake with poor debug environment on eval hardware.
- Compiling for target processor and unit test on eval hardware and target hardware reduce bugs which causes are difference of development environment between host and target.
We don't need check logical mistake of module on eval hardware. Reducing unproductive work make us concentrate on spend enormous effort for advanced work.
We need to write unit tests consistently for dual target testing
We need to write many unit test code for dual target testing. This is more a time-consuming way than moving to eval hardware without tests.
It is very easy to check with eval hardware without unit test but everything needs to be done manually. Keeping quality is very difficult if everyone commit lots of code. We spend much time to find cause of bugs.
Writing unit tests for dual targeting test is very time-consuming way in the short term but it is very productive way in the long term because we can find mistake quickly. We reduce debug time and we can spend more advanced work.
We will talk which style is good for us at the next meeting.
How can we do dual target testing?
I will explain detailed techninque for dual target testing next time. Stay tuned :)