Intro to Test-Driven Development

The book Test driven development for embedded C or TDD for embedded C was an eye-opener experience. The first time I heard about TDD was in Embedded.fm podcast. They invited James Grenning, the author of TDD for embedded C, to the show.

What is TDD about?

TDD is a technique for software development. That’s right… The goal is to develop software in small steps at a rapid and steady pace.

You test each step before start working on the next one. In that way, you can detect bugs in the early stages. And also since you already tested previous steps. You could know where exactly where the cause of failure or error is.

It doesn’t mean that with TDD your code will be perfect. A bug-free code. But you will have:

• Fewer bugs: no code is perfect. But many bugs are preventable.
• Less debug time: that’s a side effect of having fewer bugs.
• Peace of mind: testing gives you confidence that your code works.
• Good design: with TDD, you will end up with small, simple, testable and working building blocks.

Debug Later Programming (DLP)

Can you find the bug in the following piece of code? You have 5 minutes…

int16_t square_x(int16_t x)
{
    return x*x; 
}

If you haven’t tried. Then go back and try.

Okay, now… If you are here it means you tried. So

If you succeed, congratulations. If you couldn’t do it. Don’t worry. You are here to learn.

Before I reveal the bug. Imagine that in your project you use the square_x function in multiple functions. Like in the picture.

After a long day of coding. You compile your code. Run it. And…

Oh, shit!… 50% percent of your functions don’t behave as they should.

So the next question is… “where the hell is the bug?”

Probably, you should go line by line to find the infamous bug.

Let me ask you something. How long would you think you need to find the bug? Any idea? If you don’t have hundreds of lines of code. Probably, a couple of hours or some days. If not more.

The situation you just imagined is typical debug later programming or DLP. But… What if you had used a testing framework?

TDD vs DLP

What if you have a testing framework that gives you the following output.

-------------------
FAILED TEST SUMMARY
-------------------
[test_LedDriver.c]
  Test: test_square
  At line (13): "Expected 1000000 Was 16960"

--------------------
OVERALL TEST SUMMARY
--------------------
TESTED:  1
PASSED:  0
FAILED:  1
IGNORED: 0

Do you think you could know where the bug could be? And how long do you need to fix a function like square_x? Probably, a few minutes.

That’s the power of TDD vs DPL. Especially if your tests are FIRST.

• Fast: virtually zero building and execution time.
• Isolated: All tests are independent.
• Repeatable: That means automated.
• Self-verifying: They report OK or FAIL.
• Timely: Write them before production code. Providing a safe path and preventing bugs.

Smart Debugging

The testing framework showed us that there is an error with square_x. The test I used was the following:

void test_square(void)
{
    int16_t x = 1000;
    int32_t y = 0;
    y = square_x(x);
    TEST_ASSERT_EQUAL_INT32(1000000,y);
}

If you look at test_square. You can see that I defined a variable y as int32_t. I used y as an output of square_x. Because I wanted to test my implementation of the square function for int16_t values.

I was tired when I coded square_x. That’s why I didn’t notice that I defined square_x like this

int16_t square_x (int16_t x);

But thankfully I used TDD. And my tests showed me where the error was.

Now square_x looks like this:

int32_t square_x (int16_t x);

The testing framework approves it:

--------------------
OVERALL TEST SUMMARY
--------------------
TESTED:  1
PASSED:  1
FAILED:  0
IGNORED: 0

That’s what I call smart debugging.

Conclusion

TDD is a powerful technique for software development. It has many benefits. Fewer bugs, less debug time and confidence in your code. But it’s not perfect. Maybe you miss test scenarios. Maybe you make mistakes in your test code.

But. If TDD helps you to develop better code in less time. Why don’t use it?

Get one copy Test driven development for embedded C on amazon.