On Thu, 22 Jul 2010, Barry Warsaw wrote:
> >But assuming that in longer run we agree on how we invoke unittesting for
> >Python modules we ship[...]
> I propose this be spelled: 'python setup.py test'.
> In my copious spare time <wink>, I'm working on code, documentation, and
> infrastructure to make this the preferred way of testing Python modules and
> applications. You don't *have* to conform, but we'll put out big carrots for
> you if you do.
;-)
does setup.py test just do unittesting? or + doctesting, regressions,
examples, ... ?
doesn't it re-build module first?
do you advocate also 'module.test()' may be for testing already
installed module whenever setup.py is no longer there?
Altogether setup.py test sounds like a viable solution for testing
within build tree (thus rebuilding the module/extensions); and I did see
some projects to provide similar targets (some times called
differently, e.g. nosetest, although 'test' sound better ).
But it doesn't provide means for testing of already built/installed
module. Somewhat native approaches for this:
* having module.test, so we could just
python* -c 'import module; module.test()'
but that implies upstream willing to do so or our duty to hack it up
* using
nosetests module
but that is not guaranteed to work. Although nose's discovery is nice
etc, project which is not 'nose aware' might get all kinds of
side-effects while invoking tests this way.
on the other hand
nosetests --with-doctests ...
is very nice, but once again, some projects might not care about
doctests
So, altogether, all those approaches require all upstreams to agree upon
the way things get tested... which I doubt would happen.
To account for heterogeneity among the projects why instead we just
not agree upon few debian/rules targets, e.g.
debian/rules test-available-*
to run unittest battery (possibly with doctests and
whatelse) with module.test() or
nosetests or whatever upstream's native way.
Rule might need to 'cd debian' or some other directory to assure
that local source tree is not the one getting tested.
-* is there for a python version to be used ease test-* below
debian/rules test-available
to run against all supported python versions
and, dependent on successful build
debian/rules test-*
which possibly just adjust the PYTHONPATHS and call corresponding
$(MAKE) test-available-$*
debian/rules test
to test them all
Then for the validation of the packages which could just use
test-available and test targets within extracted source package
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100722140050.gn16...@onerussian.com
