Why Did Some Dog Not Bark?

In an earlier post I had described as to how unit tests are "dogs that should not bark". Meaning that Unit tests run "All Green" as code is added, modified, refactored. When a unit test fails, prompt action is taken to get back to an "All Green" state.

One situation when "silent dogs" should be a serious concern is when the signature of a function is changed. That means unit test for the function is missing. That means TDD was not followed. That means a Defect in the Process.

Another situation is when a defect is discovered while inspecting the code. A little while back I had experience of that.

It was an expression that computed the radius of a circle given the length of a chord and the distance of the midpoint of the arc from the chord. High school stuff. The expression was correctly worked out in the explanatory documentation. But in the code I forgot to divide the expression by 2. I plugged the function into the module and merrily carried on. The defect was found by a member of the team that I was coaching. I asked for comments from the team. The best answer: "The dog did not bark". I had the satisfaction of knowing my coaching had been effective😊

I had not followed TDD. My Process Had been Defective. 😢

Lesson: No matter how simple the algebraic expression, use TDD to implement the function.

Pre-Conditions, Post-Conditions & Unit Tests

Recently I wrote a class for program flow-graphs. Writing unit tests, it turned out, required more effort than the unit tests that I had written for other classes .

I was aware that when writing functions one must document the pre-conditions and the post-conditions. These I implemented as asserts. I usually felt that these were adequate. But when it came to the program flow-graph methods, the set of asserts was turning up to be just too messy

As I mentioned, the development of unit tests was turning out to be more difficult. The program flow-graph object to be used for the test had to be decided. What it would be transformed to was to be worked out. I found myself putting these down, in the test case file, as a file comment block. While doing that, I realized I was effectively specifying Pre-Conditions and Post-Conditions. I was saying, "Given this program graph object as the input, some set of attributes should change, and some set of attributes should remain invariant".

Light-Bulb event: Unit tests are statements of Pre-Conditions and Post-conditions.

What about asserts? I now regard these as micro unit tests that are embedded in the code.

PS: I hope to be more frequent in my posts in 2014:-)
Happy New Year.

Test Driven Development

For the past few months I have had to write C code. As some readers of this blog would know, for the past decade I have been preaching, or to use a more polite term - evangelizing, a great deal about software process and about coding practices. All of what I preached was from books that I read. What I read had enlightened me as to the mistakes I had when I was coding over the preceding decade.

The code has to be in C. I wanted to do test driven development. When I had tried to introduce unit testing in our compiler work at acmet, a major problem was the non-availability of a suitable C unit testing tool. This time around I came across the book Test Driven Development for Embedded C. It describes the use of CppUTest. I have gone through about half the book. That is sufficient for my present requirement. All the code that I am now writing is test driven.

A few weeks ago, I had to provide code for a small problem posed by one of our development teams. I found refactoring my code to create the needed modules much less of a problem than I had imagined. I could not have done it quite that easily had I not had the units tests. The discipline of TDD I found leads to far easier and better modularization. I could with full confidence hand over the modules to the concerned team.

For those doing embedded systems programming in C, I strongly recommend adopting the methods described in the book