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

Re: Proposed policy amendment: test suites



-=| gregor herrmann, Mon, Jul 18, 2011 at 05:59:55PM +0200 |=-
> === 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.

+1. Thanks for wrapping it up!


Reply to: