Author Archives: jwgrenning

About jwgrenning

Hi I've been developing and managing software for decades now. Starting in embedded, but doing more than embedded. Many of the mainstream software development techniques have crossover value to embedded. My mission is to spread some of those techniques to the embedded community. My company is Wingman Software. Please visit my site.

TDD and the Real-World

Posted on by
Reply

One of the attendees of my training objected to TDD stating “TDD does not resolve the real-world (temperature, pressure, timing, noisy signals, etc.) issues that my project is encountering.”

You are right! I’ll add TDD does not resolve anything. TDD is not a magic incantation that solves any problem the embedded developer may encounter. From discussions at your company, I think you realize this. But it does not change the fact that you have to spend a lot of time chasing these kinds of problems. So let’s see how TDD can support this activity.
Continue reading →

Unit testing RTOS dependent code – RTOS Test-Double – Part 3

Posted on by
6

I’m going to bend the example a little, and look at how to write tests that interact with an interrupt service routine and again with a semaphore. I’ll also get some help with the tedious parts of building fakes by using Mike Long’s Fake Function Framework. (BTW: I am using a beta version, that has changes the released version does not yet have.)

This figure shows the concurrent runtime relationship between the MessageProcessor and its SerialDriver.


Continue reading →

Unit testing RTOS dependent code – RTOS Test-Double – Part 2

Posted on by
5

In the last article, the OSSemPend() test-double was coded to handle a specific OSSemPend() application and test need. The semaphore was being used to signal when there is a message to process. It was the first need for a OSSemPend() test double and was quickly developed. As more RTOS dependent code is brought under test, a more general solution will be needed.

In this article, we’ll look at a test double that can be customized for each application.
Continue reading →

Unit testing RTOS dependent code – RTOS Test-Double – Part 1

Posted on by
17

When you’ve got legacy code that depends on the Real-time Operating System, you have a challenge to get your code off the target for unit testing. If you want to test with the concurrency provided by the RTOS, these are not really unit tests, and you won’t be able to write thorough tests, and you need unit tests to be through.

You’re going to need to make a test-double so you can get your code off the RTOS and into your development system for unit testing. In this article we’ll go through the steps to get started.

Continue reading →

Code Coverage’s Mixed Message

Posted on by
5

I’m in agreement with Robert Glass when he says “100% test coverage is insufficient. 35% of the faults are missing logic paths.” It’s not controversial, but I’d like to give my perspective on it.

If you have an automated unit test suite, low code coverage is an indication that you need more tests. Unfortunately, high code coverage does not tell you if you have enough tests or the right tests. Adding to Robert Glass’ observation, executed code is not necessarily tested code. Imagine a test case that runs through many lines of code, but never checks that they are doing the right thing. At best this is the “I don’t have any bad pointers” test.
Continue reading →

Hiding Non-standard C Keywords for Off-Target Testing

Posted on by
10

Some silicon vendors extend the C language so the programmers can easily interact with the silicon. Using these extensions tie production code to the silicon vendors compiler and consequently the code can only run on the target system. This is not a problem during production, but is a problem for off-target unit testing.

The good news is that we may be able to get around this problem without having to change production code, one of our goals when adding tests to legacy code.
Continue reading →

#include Test Double

Posted on by
7

It’s day one of adding tests to your legacy C code. You get stopped dead when the compiler announces that the code you are coaxing into the test harness can’t be compiled on this machine. You are stuck on the Make it compile step of Crash to Pass.

Moving your embedded legacy C code (embedded C code without tests) into a test harness can be a challenge. The legacy C code is likely to be tightly bound to the target processor. This might not be a problem for production, but for off-target unit testing, it is a big problem.

For C we have a limited mechanisms for breaking dependencies. In my book, I describe at length link-time and function pointer substitutions, but only touch on preprocessor stubbing.

In this article we’ll look at #include Test-Double as a way to break dependencies on a problem #include file.

Continue reading →

Manual Test is Unsustainable

Posted on by
13

Creating automated tests can be very difficult, especially when the code has gotten long in the tooth and was not created with automated tests to begin with. Many product development teams don’t invest in automated tests. They think they cannot afford them. They think their product is different and can’t be tested automatically. This thinking is flawed.

Back in the products younger days, manual test was not too time consuming. But slowly that changed. The system grows, the manual test effort grows. Eventually, it seems that no amount of manual test effort finds all the problems.

In this article I show a simple model that illustrates why manual test is unsustainable and that a sustainable software product development effort must include considerable test automation.

Continue reading →

Wishing for a Command Line Interface

Posted on by
6

I have a few courses that share materials and ideas. I used to use the age-old practice of cut and paste to share the slides. As handy as it is, cut and paste causes trouble. If I’m teaching TDD in C and make a change to a discussion that applies also to C++ or or some other language, I’ve got a problem. I’ll never remember to put the change in the other places where the change is needed. This means that later I find myself in front of a group of C++ programmers about to make a big point, and find that the dramatic conclusion added to the C version I made is not in the current slide deck.

As with code, duplication in presentations is a liability. So I needed to refactor my training materials, and need a practical way to deliver them and provide a PDF handout of the presentation.
Continue reading →

The Careful way is the Fast Way

Posted on by
2

After the Agile2011 conference, my wife and I took some great hikes in the mountains of Utah. We were careful as we navigated the slot canyons, rushing streams, and falling water. We were careful, we did not want a mistake to cause an injury; but we have no fear of height and love adventure. After a few days of hiking, our skill grew and we worked the terrain more quickly and safely.

I’ve described TDD using the analogy of stepping stones to cross a river for years. Here’s a Utah stream coming from a slot canyon.

You can see there are a few ways across. It’s not a straight path, but with a few careful steps you get to the other side, keeping your shoes dry.

Over several days of hiking, I discovered another metaphor for TDD, often thought of as a very careful way to program. The careful way is the fast way.

Continue reading →