blog/posts/2011/07/Test_Driven_Development_in_Debian.mdwn

   1 # ... or TDDD and [DEP8](http://dep.debian.net/deps/dep8/)
   2
   3 ## context
   4
   5 As a nice byproduct of the huge
   6 ["rolling" discussion](http://lists.debian.org/debian-devel/2011/05/msg00111.html)
   7 we had back in April/May, various people have brainstormed about applying
   8 [[!wikipedia Test-Driven Development]] (TDD) techniques to Debian development.
   9 Here is a brief summary of some opinions on the matter:
  10
  11 * a [seminal conversation](http://identi.ca/conversation/70061026) on identi.ca
  12 * a couple of [blog](http://blog.liw.fi/posts/debian-tdd/)
  13   [posts](http://blog.liw.fi/posts/debian-tdd-2/) by
  14   [Lars](http://blog.liw.fi/englishfeed/), discussing the general problem of
  15   how to use TDD in *distribution* development and — to a lesser extent — its
  16   instantiation to Debian
  17 * a [separate post](https://www.debian-administration.org/users/dkg/weblog/80)
  18   by [Daniel](http://debian-administration.org/users/dkg/weblog) stressing the
  19   specific TDD advantage of increasing the confidence of maintainers in making
  20   far reaching changes
  21
  22 ... and hey, they've also coined the cool **TDDD** acronym, which I hereby took
  23 the freedom to re-target to **Test-Driven Development in Debian**. Having a
  24 cool acronym, we are already half-way to actually having the process up and
  25 running `*g*`.
  26
  27 ## more testing
  28
  29 I believe **Debian needs more testing** and I've been advocating for that since
  30 quite a while —
  31 e.g. [at DebConf10](http://penta.debconf.org/dc10_schedule/events/569.en.html),
  32 as one of the main goals we should pursue in the near future. Of course
  33 advocating alone is not enough in Debian to make things happen and that is
  34 probably why this goal has been (thus far) less successful that others we have
  35 put forward, such as
  36 [welcoming non-packaging contributors](http://www.debian.org/vote/2010/vote_002)
  37 as Debian Project members. There are important reasons for increasing testing
  38 in Debian.
  39
  40 ### quality assurance
  41
  42 Quality Assurance has always been, and still is, one of the distinctive traits
  43 of Debian. I often say that Debian has a widespread <q>culture of technical
  44 excellence</q> and that is visible in several places: the
  45 [Debian Policy](http://www.debian.org/doc/debian-policy/) *process*,
  46 [lintian](http://lintian.debian.org/), [piuparts](http://piuparts.debian.org/),
  47 periodic full archive rebuilds, the
  48 [EDOS/Mancoosi QA tools](http://edos.debian.net), the cultural fact that
  49 maintainers tend to know a lot about the software they're packaging rather than
  50 only about packaging, the <q>we release when it's ready</q> mantra, etc.
  51
  52 But caring about quality is not a boolean, it's rather something that should be
  53 continuously cherished, refining quality requirements over time. By simply
  54 maintaining the *status quo* in its QA tools and processes, Debian won't remain
  55 for long a distribution who could claim to care about package quality.  Others
  56 *will* catch up and are in fact already doing that.
  57
  58 In particular, we surely have room for improvements in our quality tools and
  59 processes for:
  60
  61 * **Build time package testing.** Several packages run their build-time test
  62   suites during package build. This aspect is somewhat
  63   [supported](http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options)
  64   by the Debian policy; we also do a best effort attempt to run build-time test
  65   suites
  66   [via debhelper](http://manpages.debian.net/cgi-bin/man.cgi?query=dh_auto_test)
  67   (starting from version 7). At the same time we could probably campaign more
  68   to encourage maintainers to look for build-time test suites which do not
  69   follow common Makefile target naming or, fwiw, which don't rely on make at
  70   all.
  71
  72   `TodoList.add("investigate and possibly file bug report against policy to
  73   encourage maintainers to run build-time test suites")`<br />
  74   `TodoList.add("investigate and possibly file bug report against lintian to
  75   spot the presence of [non-invoked] build-time test suites")`
  76
  77 * **Runtime package testing** (AKA "as-installed package testing"). Some kinds
  78   of test-suites are difficult to run at build-time (e.g. complex applications
  79   that don't offer easy way to re-configure on the fly their filesystem paths)
  80   and some others are plainly impossible to run without having the packages to
  81   be tested properly setup (e.g. running services that are accessible only
  82   through the network) or an isolated, throw-away [[!wikipedia testbed]]
  83   (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not
  84   currently in use neither in Debian nor, indirectly, in any of its
  85   derivatives.  [[!debpkgsid autopkgtest]] (AKA
  86   [DEP8](http://dep.debian.net/deps/dep8/)) is a step in this direction; I will
  87   get back to it later on in this post.
  88
  89 * **Integration testing.** When applied in the context of distributions,
  90   [[!wikipedia integration testing]] is about testing package combinations,
  91   task (as in [[!debpkgsid tasksel]]) combinations, basic system
  92   functionalities, automated installations, etc. This is the aspect that Lars
  93   has discussed [the](http://blog.liw.fi/posts/debian-tdd/)
  94   [most](http://blog.liw.fi/posts/debian-tdd-2/) (and in which he seems to be
  95   *interested* the most) so I don't feel like adding much.
  96
  97   Still, it's interesting to note that on this front Debian has an important
  98   potential to exploit. The large base of its developers and the fact that the
  99   average Debian user is technical savvy mean that we can potentially collect a
 100   lot of test cases. It's "just" (with well-deserved double quotes) a matter of
 101   deciding a standard interface for test case submissions and developing a —
 102   most likely virtualized — test runner. At that point a continuous integration
 103   service that periodically run and publishes results can be setup
 104   independently from the rest of the Debian infrastructure and offered to
 105   interested eyes, such as Release Team's. Any taker?
 106
 107 * **Automated code analysis** and in particular automated bug finding is
 108   something which is becoming more and more common and — finally, after decades
 109   of research — viable. Successful proprietary tools and businesses are aplenty
 110   (a nice and very fun read on the subject is the story of
 111   [Coverity](http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext)),
 112   as well as FOSS solutions. For instance, the Linux kernel is routinely using
 113   [Coccinelle](http://coccinelle.lip6.fr/) to
 114   [automatically find bugs](https://lwn.net/Articles/315686/) and even produce
 115   the corresponding patches.
 116
 117   Add to the above the fact that Debian is one of the largest software
 118   collection in existence (and quite probably *the* largest collection of
 119   *Free* software in existence) and is upstream of the packaging of that
 120   software for the most part. That turns Debian into a very peculiar platform
 121   for large scale automated code analyses. Not that we can aim at fixing all
 122   the bugs we are going to find, or even hope to tame all the *false positives*
 123   we are going to find. But we can offer an important service to the whole
 124   ecosystem of Free software and use it to pinpoint important class of bugs
 125   from a distribution point of view, such as nasty security bugs (as long as
 126   they can be automatically found…).
 127
 128   [DACA](http://lists.debian.org/debian-devel-announce/2010/12/msg00003.html)
 129   is a very good step in the right direction, even though it is still in its
 130   infancy.
 131
 132 ### reducing inertia
 133
 134 Inertia is a recurring topic among Debian lovers (and haters). It is often
 135 argued how difficult it is to make changes in Debian, both small and large, due
 136 to several (alleged) hindrances such as the size of the archive, the number of
 137 ports, the number of maintainers that should agree before proceeding with a
 138 cross-package change, etc. It's undeniable that the more code/ports/diversity
 139 you have, the more difficult is to apply "global" changes. But at least for
 140 what concerns the archive size, I believe that for the most part it's just FUD:
 141 simply debunking the
 142 [[self-inflicted culture about how "dangerous" doing NMUs is|hacking/debian/rcbw]]
 143 might go — and has already gone, imho — a long way to fight inertia.
 144
 145 Adding per-package and integration tests will make us go another long way in
 146 reducing inertia when it comes to performing archive-wide changes. Indeed if a
 147 package you are not entirely familiar with has extensive test suites, and if
 148 they still pass after your changes, you can be more confident in your changes.
 149 The barrier to contribution, possibly via NMU, gets reduced as a result. And if
 150 your change will turn out to be bad but still not spot by the test suites, then
 151 you can NMU (or otherwise contribute) again to extend the test suite and make
 152 the life easier for future contributors to that package. It smells a lot like
 153 an useful virtuous cycle to me.
 154
 155 ## autopkgtest / DEP8 — how you can help
 156
 157 Of all the above, the topic that intrigues me the most is as-installed package
 158 testing. Work on that front has been started a few years ago by Ian Jackson
 159 when he was working for Canonical. The status quo is embodied by the
 160 [[!debpkgsid autopkgtest]] package. At present, the package contains of various
 161 tools and the following two specs:
 162
 163 1. `README.package-tests` provides a standard format to declare per-package
 164   tests using the new `debian/tests/control` file. Tests come as executable
 165   files which will be run — by the `adt-run` tool — in a testbed where the
 166   package(s) to be tested is already installed.
 167
 168   This part of the specs has been reified as
 169   [DEP8](http://dep.debian.net/deps/dep8/) which I'm (supposedly) co-driving
 170   with Iustin Pop and Ian (for well-deserved credits).
 171
 172 2. `README.virtualisation-sever` describes the interface among the test runner
 173   and the testbed. A nice separation is provided among the runner and the
 174   testbed, enabling different testbed environments with a varying degree of
 175   isolation: you can have a "null" testbed which runs tests on your real
 176   machines (needless to say, this is highly discouraged, but is provided by the
 177   `adt-virt-null` tool), a chroot testbed (`adt-chroot`), or a XEN/LVM based
 178   testbed (`adt-virt-xenlvm`).
 179
 180 The specs allow for several runtime testing scenarios and look quite flexible.
 181 The tools on the other hand suffer a bit of bitrot, which is unsurprisingly
 182 given they haven't been used much for several years. At the very minimum the
 183 following Python development tasks are in need of some love:
 184
 185 * The usage of python-apt needs to be ported to recent API, as several used
 186   methods and attributes are now gone.
 187 * Porting from dchroot to schroot is needed for the `adt-virt-chroot` backend.
 188 * A kvm backend for the test runner would be nice.
 189
 190 If you are both interested in TDDD and grok Python, the above and many others
 191 tasks might whet your appetite. If this is the case don't hesitate to
 192 [contact me](mailto:zack@debian.org), I'll be happy to provide some guidance.
 193
 194 ----
 195
 196 Note: this post is the basis for the
 197 **[TDDD BoF](http://penta.debconf.org/dc11_schedule/events/764.en.html)** that
 198 I will co-host with Tom Marble at [DebConf11](http://debconf11.debconf.org). If
 199 you plan to come, we will appreciate your thoughts on this matter as well as
 200 your help in getting the `autopkgtest` toolchain up and running again.
 201
 202 [[!tag lang/english planet-debian debian tddd dep8 debconf11]]