I write a fair number of Unix command line programs, and I want to
have test suites for them. A year and a half ago I wrote a tool to
make that easier:
cmdtest. However, it turned out to not be a
particularly good one, primarily because it doesn't make it easy to
write good test code. Tests and test code should be obviously
correct, so you don't need a test suite for your test suite.
Earlier this year,
Daniel and I started a slow, but long discussion
about this. We'd talk it over during many a lunch, figuring out what
we actually want. We eventually converged on an approach based on
for Unix command line programs, and based on
Markdown documents.
We then wrote that up as a
README, and then took another month
refining the README before writing any code. The naming discussion
only took a week.
- We borrowed the given/when/then structure from BDD, and the idea of
using that structure so that tests are specified using lightly
structured text in a way that allowsnon-developers to participate.
- This borrowed structure gives a way to express sequences of things
that happen, including setup and checks. We call these sequences
test scenarios, and thus this approach to testing is called scenario
testing.
- We embed the test scenarios, and the code that implements them, as
code blocks in Markdown documents. This makes it easy to explain
what is going on in the tests, when that's needed, right next to the
tests. The Markdown files can easily be formatted as web pages or
PDFs (among other formats), making it easy to share and discuss them
with people who might not be comfortable accessing a git repository.
As a concrete example, here is a real test scenario, from Obnam, for
testing its new FUSE plugin:
SCENARIO Browsing backups with FUSE plugin
ASSUMING user is in group fuse
GIVEN a live data directory
AND a 0 byte file called empty
AND a 1 byte file called one
AND a 4096 byte file called 4k
AND a 10485760 byte file called 10meg
AND a hardlink to 4k called 4k-hardlink
AND a symlink to 4k called 4k-symlink
AND a directory called some-dir
AND a symlink to ../4k called some-dir/other-symlink
WHEN live data is backed up
AND repository is fuse mounted
THEN latest generation can be copied correctly from fuse mount
FINALLY unmount repository
Some explanations:
SCENARIO is the name of the scenario.ASSUMING is a condition for the entire scenario: the FUSE plugin
can only be tested when the user can use FUSE.GIVEN is a setup step, WHEN is the step that does the thing that
is being tested, and THEN checks that the right thing happened
during WHEN.AND is an alias for the keyword on the previous line; it makes the
test scenario seem more like normal English textFINALLY is for cleaning up afterwards, whether the scenario passed
or not
Test scenarios like this are obviously not directly executable. We
need to provide the code that actually executs each step. For this,
yarn provides an IMPLEMENTS section, of which I will show one
example: the creation of the files.
IMPLEMENTS GIVEN a (\d+) byte file called (\S+)
dd if=/dev/zero of="$DATADIR/live/$MATCH_2" bs=1 count="$MATCH_1"
(The other IMPLEMENTS sections for that Obnam test scenario are also
only about a line of shell. The longest one is four lines, because it
has an
if statement that I like to format in a fairly verbose
way. I'm skipping the others to avoid needless repetition.)
The text after the keyword (GIVEN, WHEN, THEN, etc) in the test
scenario is a single line of free-form text, which is matched by a
regular expression in the IMPLEMENTS section. There must be exactly
one matching IMPLEMENTS for each line in a test scenario.
The body of IMPLEMENTS is a shell script snippet. Yarn provides a
temporary directory for each scenario, and the path to that is given
in the
DATADIR environment variable. Yarn also cleans up the
directory afterwards, unless the user running yarn requests otherwise,
so tests that only change things in the temporary directory don't need
any FINALLY steps. The above example uses FINALLY to unmount the FUSE
filesystem at the end.
The regular expressions can capture parts of the text in the scenario
step, and these are provided to the shell script using environment
variables:
MATCH_1 etc. This is a simple, but powerful mechanism for
implementing very flexible steps, which also means the number of steps
can be kept down.
The IMPLEMENTS sections are shared between all test scenarios. This
makes it very easy to write new scenarios using already-existing
steps, by choosing which ones to use, in which order, and making use
of any variability in the steps that their implementations provide.
Yarn is a new tool, and I expect it to mature in the coming
months. It's included in the cmdtest Debian package, and is already in
Debian jessie and unstable, for those who want to try it. (My personal
apt repository has a .deb for wheezy as well; backports are welcome).
The yarn scenario testing language itself is not set in stone, but
Daniel and I both want to be careful about making changes to it. It's
all meant to be very simple: an obviously correct testing tool is
better than an intricate one.
I've used yarn in several of my own little programs now, as has
Daniel, and we've used it at
work as well. Undoubtedly we'll find
bugs in the implementation, and we're still feeling our way to
figuring out how to write really excellent scenarios, and how to
structure steps with the best possible taste. We'll also start
designing a shell library that yarn provides to the IMPLEMENTS
sections, for doing things that we find ourselves doing in many
projects.
It is already clear to me, however, that yarn is oh so much better
than cmdtest could ever be. I'm even starting to express ideas for new
tools as yarn test documents, so I'm clear what they should do. If and
when I ever get to actually implementing the tools, I'll have a test
suite for them already. See, for example, first attempts at specifying
how a fast file transfer tool,
fling, which is to use Linux-only
system calls to reach wire speeds over wired LAN, and a tool to
recompress compressed files with another compression tool.
We hope yarn will prove to be useful for others as well. If you try
it, and have suggestions or comments, please e-mail us.
FrOSCon is approaching, and
all MirBSD developers will attend but why s there no MirBSD exhibit?
The answer to that is a bit complex. First let s state that of course
we will participate in the event as well as the Open Source world.
We ll also be geocaching around the campus with other
interested (mostly OSS) people (including those we won for this sport)
and helping out other OSS projects we ve become attached to.
MirOS BSD, the operating system, is a niche system. The conference
on the other hand got younger and more mainstream. This means that
almost all conference visitors do not belong to the target group of
MirOS BSD which somewhat is an ancient solution : the most classical
BSD around (NetBSD loses because they have rc.d and PAM and lack
sendmail(8), sorry guys, your attempt at being not reformable doesn t
count) and running on restricted hardware (such as my 486SLC with 12
MiB RAM) and exots (SPARCstation). It s viable even as developer
workstation (if your hardware is supported otherwise just virtualise
it) but its strength lies with SPARC support and embedded x86 . And
being run as virtual machine: we re reportedly more stable and more
performant than OpenBSD. MirBSD is not cut off from modern development
and occasionally takes a questionable but justified choice (such as
using 16-bit Unicode internally) or a weird-looking but beneficial
one (such as OPTU encoding saving us locale(1) hassles) or even acts
as technological pioneer (64-bit time_t on ILP32 platforms)
or, at least, is faster than OpenBSD (newer GNU toolchain, things
like that), but usually more conservatively, and yes, this is by
design, not by lack of manpower, most of the time.
The MirPorts Framework, while technically superiour in enough
places, is something that just cannot happen without manpower.
I (tg@) am still using it exclusively, continuing to update ports
I use and occasionally creating new ones (mupdf is in the works!),
but it s not something I d recommend someone (other than an Mac OSX
user) to use on a n n-MirBSD system (Interix is not exactly thriving
either, and the Interix support was only begun; other OSes are not
widely tested).
The MirBSD Korn Shell is probably
the one thing I will be remembered for. But I have absolutely no idea
how one would present it on a booth at such an exhibition. A talk is
much more likely. So no on that front too.
jupp, the editor which sucks less,
is probably something that does deserve mainstream interest (especially
considering Natureshadow is using it while teaching computing to kids)
but probably more in a workshop setting. And booth space is precious
enough in the FH so I think that d be unfair.
All the other subprojects and side projects Benny and I have, such
as mir c ,
josef stalin, FreeWRT, Lunix Ewe, Shellsnippets, the fonts, etc. are
interesting but share few, if any, common ground. Again, this does not
match the vast majority of visitors. While we probably should push a
number of these more, but a booth isn t it here, either.
MirOS Linux ( MirLinux ) and MirOS Windows are, despite otherwise-saying
rumours called W*k*p*d*a, only premature ideas that will not really be
worked on (though MirLinux concepts are found in mir c and stalin).
As you can see, despite all developers having full-time dayjobs,
The MirOS Project is far from being obsolete. We hope that our website
visitors understand our reasons to not have an exhibition booth of our
own (even if the SPARCstation makes for a way cool one, it s too heavy
to lift all the time), and would like to point out that there are several
other booths (commercial ones, as well as OSS ones such as AllBSD, Debian
and (talking to) others) and other itineries we participate in. This year
both Benny and I have been roped into helping out the conference itself,
too (not exactly unvoluntarily though).
The best way to talk to us is IRC
during regular European geek hours (i.e. until way too late into the
night which Americans should benefit from), semi-synchronously, or mailing lists. We sort of expect you
to not be afraid to RTFM and look up acronyms you don t understand;
The MirOS Project is not unfriendly but definitely not suited for your
proverbial Aunt Tilly, newbies, desktop users, and people who aren t
at least somewhat capable of using written English (this is by design).
[still no pictures here, feel free to go to 
It'd be easy to assume that in a Mir-based world, the Mir server receives input events and hands them over to Mir clients. In fact, as I described 
On the last day of DebConf 13, RichiH and Ganneff and I set up a
git-annex repository that all Debian developers have automatic
commit access to, and
As I slowly read my good friends wishing each other a good trip, telling they got home safely, and the IRC channels form thick drops of a bitter-sweet etheral substance, I cannot help feeling DebConf13 is over For me as well, from the distance. Many friends gave me warm greetings, and without being there, gave me that beautiful feeling of real community that Debian has given me for ten years already, since I met in real-life many of its developers at DebConf3 in Oslo. And yes, I have stated this far too many times I have attended every DebConf since (and worked organizing most of them). This year, 
WebRTC: premium voice/video chat in modern browsers, no plugin required
Another member of Debian's GSoC program, 
As the grand finale, we took 
The grand-finale of the 
Somehow last year I missed the fact that I've been around 
This weekend I'm mostly alternating between reading, writing, and trying to avoid death by the plague.[*]
I've switched Lumail to using a UTF-8 aware string library, which means we can now handle the obvious case:
The 
Choosing Embedded Processors for AltOS
When Bdale and I started building rocketry hardware together, we had
already picked out a target processor, the TI
XInput2 has the ability to deliver raw device events right to
applications, bypassing the whole event selection mechanism within the
X server. This was designed to let games and other applications see
relative mouse motion events and drawing applications see the whole
tablet surface.
These raw events are really raw though; they do not include the
cursor position, and so cannot be directly used for tracking.
However, we do know that the cursor only moves in response to input
device events, so we can easily use the arrival of a raw event to
trigger a query for the mouse position.
A better plan?
Perhaps what we should do is to actually create a new event type to
report the cursor position and the containing window so that
applications can simply track that. Yeah, it s a bit of a special
case, but it s a common requirement for accessibility tools.
On the final day of DebConf, Saturday 17 August, there is an afternoon track dedicated to the topic of 
A week or so back, I was at a customer to upgrade his server to
wheezy. This server had originally been installed, not as squeeze but as
something older, and was installed using an LVM-on-mdraid setup.
Booting off such a setup (without a /boot partition outside of the
raid/LVM) is certainly possible with several boot loaders, including
grub2; however, it was having issues in this particular instance,
producing an error message along the likes of:
