Re: Build-time testing
FWIW I usually prefer to run unittests against (PYTHONPATH)
installed (debian/tmp/... if with extensions to be moved into -lib, or
debian/python-X/... for pure Python module) version to make sure that
everything got installed correctly. Also, if not too lengthy, I run
unittests against all supported Python versions.
Altogether, it does make things a bit more "cumbersome" but more
reliable.
Examples:
http://git.debian.org/?p=pkg-exppsy/brian.git;a=blob;hb=HEAD;f=debian/rules
https://github.com/neurodebian/dipy/blob/HEAD/debian/rules
on a related note, more I hit it:
- I set $HOME to point to build/, and at times MPLCONFIGDIR=$(HOME)
where I
echo "backend : Agg" >| $(MPLCONFIGDIR)/matplotlibrc
to assure consistent matplotlib backend if graphics are built during
documentation generation
And indeed, written recommendations would be nice ;)
On Tue, 22 Feb 2011, Andrey Rahmatullin wrote:
> Hello.
> Many Python modules ship unit tests which do not require module
> instalation or user interaction and so can be run automatically during the
> build time. They can be a very good QA tool, but it looks like they are
> not used in all packages.
> python-pylons: not used
> python-pybabel: not used
> pylint: used, but produce errors which are ignored
> python-sphinx: apparently used
> In many cases $PYTHON setup.py test (for all supported $PYTHON's) is
> enough to run the tests and any errors mean that something is wrong with
> the environment (provided the tests are correct).
> Shouldn't we have some written recommendations (or even policy) on this matter?
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Reply to: