add tag interview to last post
[homepage.git] / 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]]