Raphaël Hertzog: Test Driven Development with CppUTest, now in Debian
I have recently read Test Driven Development with Embedded C by James W. Grenning and published by Pragmatic Programmers.
I really enjoyed the book: while I was aware of the huge benefits of having a comprehensive test suite, I never studied seriously the principles behind Test Driven Development (TDD) and this book makes a good introduction to the topic. At the same time it focuses on the C language and contains lots of examples on how you can create tests even for projects which have to interact with hardware or other unpredictable components (the key is to create many abstractions) using all the possibilities that C offers.
The author convincingly argues that developing code with TDD forces you to create a modular design that is easier to evolve when the underlying requirements change. He also highlights how the tests serve as reference documentation of the API.
James W. Grenning recommends CppUTest as his xUnit test framework of choice. When I wanted to try this test framework, I discovered that it was not available in Debian. I decided to package it because it has some interesting features not offered by the contenders (at least not to my knowledge). It s now available in Debian and in Ubuntu.
First, it doesn t require any explicit registration of tests and has a very lightweight syntax. The small downside is that CppUTest requires the usage of C++ for the tests. But C++ is compatible with C so it doesn t matter much if you have a C++ compiler for your target. On the contrary, usage of variables and methods scoped to the test group makes it easy to write clear tests. Here s a short sample of test code:
extern "C" #include "timer.h" #include "timefn.h" #include "CppUTest/TestHarness.h" static Time the_time; static const int start_sec = 123; static const int start_nsec = 456789000; static const int delay_sec = 8; static const int delay_nsec = 111111000; // start_nsec + delay_nsec < 10^9 TEST_GROUP(Timer) /* Class variables available to all tests in the group */ Timer timer; Delay remaining; /* Standard setup/teardown methods of xUnit tests */ void setup() timer = timer_new(); time_set(&the_time, start_sec, start_nsec); /* [...] */ void teardown() timer_free(timer); /* [...] */ /* Helper functions specific to the test group */ void start_timer_with_delay(long sec, long nsec) timer_set_real_delay(timer, sec, nsec); timer_start(timer); void ensure_remaining_is(long sec, long nsec) CHECK_EQUAL(sec, delay_get_seconds(remaining)); CHECK_EQUAL(nsec, delay_get_nanoseconds(remaining)); ; TEST(Timer, NewIsNotStarted) CHECK(!timer->started); /* [...] */ TEST(Timer, GetRemainingTimeWithNanosecondPrecision_ShiftOfSeconds) start_timer_with_delay(delay_sec, delay_nsec); time_set(&the_time, start_sec + delay_sec - 5, start_nsec + delay_nsec + 1000); remaining = timer_get_remaining_time(timer); ensure_remaining_is(4, 999999000);
#include "CppUTest/CommandLineTestRunner.h" int main(int argc, char** argv) return CommandLineTestRunner::RunAllTests(argc, argv);
The upstream developers have made some unusual choices (static library only, installation in a private directory) but this will likely change with the switch to an automake and autoconf-based build system. I have reported the oddities that I found and I requested them to provide a pkg-config file to make it easier to compile and link unit tests exploiting CppUTest.
I already used CppUTest to develop a small application running on an embedded Linux. At some point, I might try to use CppUTest for dpkg development. I believe that it makes for a good fit. dpkg is already C++ ready since dselect is written in C++ and reuses a good part of dpkg s code.
In any case, if you like Test Driven Development and are writing C or C++ based applications, I invite you to try CppUTest.
No comment Liked this article? Click here. My blog is Flattr-enabled.
However, running everything through ssh to another machine makes editing and iterating more clumsy; I need to do agent forwarding etc not terribly hard, but not free either, particularly when I travel, I need to remember to sync my source trees back to my laptop. So I prefer to live on my laptop and use my desktop for compute power.
I had a couple of Juju charms I wanted to investigate, but I needed enough compute power to make my laptop really quite warm so I thought, its time to update my local cloud provider from Eucalyptus to Openstack. This was easy enough, until I came to run Juju. Turns out that Juju s commands really want to talk to the public DNS name of the instance (in order to SSH tunnel a connection to Zookeeper).
But! Openstack returns DNS names like Server-3 , and if you think about a home network, its fairly rare to have a local DNS server *anyway*, so putting a suffix on names like that won t help at all: you either need to use a DNS naming provider (openstack ships with an LDAP provider, which adds even more complexity), and configure your clients to know how to find it, or you need to use the public IP addresses (which default to the FlatNetwork, which is routable within a home LAN by simply adding a route to 10.0.0.0/8 to your wifi interface). Adding to confusion, some wifi routers fail to forward avahi messages, which is a) terrible and b) breaks the only obvious way of doing no-config local DNS 
.
So, I did some yak shaving this morning. Turns out other folk have already run into this and filed a 
Finally I've found time to look back at vacation in Rome and post some pictures. It has been great time there and I've really enjoyed that.
I would like to thank to Luigi Gangitano for showing us some interesting places in the city.
And now back to pictures:
So status displays are cool. Seeing what is happening in real time is cool.
As a proof of concept I put together a trivial load-graph:
I have an interesting problem: How do I shoehorn "hired by The Internet for
a full year to work on Free Software" into my resume?
Yes, 
A 
I will sound monothematic, but I have been devoting quite a bit of work to this topic lately: Trying to stop the advance of e-voting in Mexico, Latin America and the world.
Why trying to stop it? Isn't technology supposed to help us, to get trustable processes? Yes, it's supposed to... but it just cannot achieve it, no matter how hard it is tried I won't get into explanations in this blog post, but there is plenty of information. Feel free to ask me for further details.
Anyway Yesterday (Sunday, 2012-06-17) was the fifth simulated voting that will lead to the first wide-scale deployment of electronic voting booths in my country: About 10% of the population of the state of Jalisco (that means, ~500,000 people) will cast their votes on July 1st electronically.
This particular case illustrates how simulated votings can be used to forge a lie: Pounce Consulting, the company that won the e-voting project for IEPC (Jalisco's voting authority), delivered their booths over 40 days late, just before the deadline for the project to be canceled. Oh, and by the way, it's the same company that just failed to deliver on time for another planned local authority (10% of the booths in the Federal District, where I live, where fortunately 100% of the votes will be cast on traditional, auditable and cheap paper).
After this delay, five voting simulations were programmed, to get the local population acquinted with them. The first ones just 
I've made some tweaks and fixes to my
A copy of this post is sent to
Carla Schroder 