[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposed policy amendment: test suites



During the last years there have been talks about which tests to
run/enable/disable/... during package build on IRC. It seems that the
preliminary results were never written down, which leads to the same
questions and the painful exercise of digging up memories :)

I'm proposing to add a section about test suites to our group policy;
for that reason I've now written down a first draft of what I think
was the consensus (added below).

Please comment/fix/improve the text; we can then either finalise it
during the BoF at DebConf next week (or commit it before, it there
are no controversies).

Cheers,
gregor

=== diff for policy.pod, without TOC and copyright years ===

Index: policy.pod
===================================================================
--- policy.pod	(revision 77577)
+++ policy.pod	(working copy)
@@ -254,6 +256,51 @@
 
 =back
 
+=head1 Test suites
+
+CPAN distributions typically come with a test suite that is run at build time.
+As a general rule, we want to run as many tests as possible in order to catch errors.
+Some details need to be taken into account:
+
+=over 4
+
+=item *
+
+We can't enable or need to disable tests that need internet access.
+(If there is no specific environment variable, a patch is required.)
+
+=item *
+
+We don't enable tests that are explicitly declared as upstream/author/release tests by the author
+(typically via an environment variable as I<RELEASE_TESTING>, I<AUTHOR_TESTING, >or I<TEST_AUTHOR>).
+
+Test designed to be run in automatic builds/installs (usually enabled by setting
+I<AUTOMATED_TESTING>) are fine.
+
+=item *
+
+Some tests are, even if not declared explicitly as release tests, a bit fragile and tend
+to break with new releases of the test modules, or test style and not functionality
+(Test::Perl::Critic, Test::Spelling, Test::Kwalitee, ...). It might be helpful to avoid running them.
+
+=item *
+
+Tests that need display access usually work with B<xvfb>:
+
+    debian/control:
+    Build-Depends(-Indep): ..., xvfb, xauth, ...
+
+    debian/rules:
+    override_dh_auto_test:
+        xvfb-run -a dh_auto_test
+
+=item *
+
+Some tests need versioned build dependencies for dual-lifed modules (e.g. B<Test::More>),
+cf. L<Build and runtime dependencies|/"Build and runtime dependencies">.
+
+=back
+
 =head1 Debian Maintainers practice
 
 The Debian project has adopted the Debian Maintainers (DM) concept (cf.

-- 
 .''`.   Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-    BOFH excuse #442:  Trojan horse ran out of hay 

Attachment: signature.asc
Description: Digital signature


Reply to: