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.

Spying on Embedded ‘asm’ directives

Posted on by
1

Sometimes embedded developers have to use inline assembler instructions to get better control of the processor, or to improve performance. How should we deal with those when we’re doing TDD and testing off the target?

What’s the problem? The embedded asm statements cause compilation errors if the assembler instructions are not part of the off-target test platform instruction set. Also some of the instructions might not be legal in the test environment. This article shows how to insert a test double for the asm directives with gcc and CppUTest.

Continue reading →

Test Before or Test After, that is the Question

Posted on by
2

In Jeff Langr’s blog, Jeff responded to an assertion (from someone Jeff calls Schmoo) that writing tests after developing a unit of production code takes less time than using TDD to create production code and its tests. For starters, I am happy the discussion is about when to write the unit tests and not if.

I think a model would help us talk about this issue. It would be great to have some real numbers in the model; that will be hard. But for starters let’s look at a model. Maybe then someone can figure out how to put some numbers to the model.
Continue reading →

Legacy Code Change – a Boy Scout Adds Tests

Posted on by
Reply

Here is a legacy code change policy for a team adopting TDD that has a legacy code base:

  • Test-drive new code
  • Add tests to legacy code before modification
  • Test-drive changes to legacy code

Refactoring without tests is dangerous; with all the details we must keep straight, a mistake is easy to make. How many code reviews have you been in where the recommended design changes are not made because “we already tested it”? You avoid the change because it’s dangerous to change code without tests. So, the Boy Scout adds tests too. For more on Boy Scouts, see previous post.

Continue reading →

Boy Scout Rule Applied to Every Day Coding

Posted on by
8

The Boy Scouts have a rule: leave the camp cleaner than you found it. This does not mean that all the trash has to be cleaned up now, but you can’t let it get worse, and it must get at least a little better. In Bob Martin’s book, Clean Code, he asks, “What if code got a little better every time you change it?” I’ll answer it: the industry would not find itself in the mess it’s in. The industry norm is for code to incrementally worsen with each change.

Much of the time, following the Boy Scout Rule won’t be hard. It’s an incremental strategy. It’s easy to start and easy to sustain. Here are some typical challenges and ideas on how to be a Boy Scout.

Continue reading →

Making Progress in Spite of Uncertainty

Posted on by
Reply

At the start of a new development effort, there is considerable uncertainty. There are unknowns in hardware, software, product goals and requirements. How can we get started with all this uncertainty? Isn’t better to wait? If you wait, there really is no end to the waiting, so its better to get started sooner even though there will be some things you decide early that get changed later.
Continue reading →

Agile Design and Embedded

Posted on by
1

One important realization on the journey from a BDUF approach to an iterative and agile approach is that design is never done. Designs evolve. The waterfall emphasis has been to unnaturally try to control software physics by imposing requirements freezes and burdensome change control. The process of developing software is part science and part creative. You are applying science toward the invention of something. Design is capturing knowledge both about what the end user need is, and one solution to that need.
Continue reading →

Why Test Driven Development for Embedded?

Posted on by
5

Embedded software has all the challenges of “regular” software, like poor quality and unreliable schedules. It is just software with some additional challenges. The additional challenges do not disqualify TDD for embedded. TDD even helps with some of those uniquely embedded challenges.
Continue reading →

What Should you Expect from a Unit Test Harness

Posted on by
Reply

A unit test harness’ job is to provide:

  • A concise common language to express test cases
  • A concise common language to express expected results
  • A place to collect all the unit test cases for the project, system, or subsystem
  • The facilities to run the test cases, either in full or partial batches
  • A concise report of the test suite success or failure
  • A detailed report of any test failures