[TIP] Tasting the Cheeseshop

[Éric Araujo]

Hi everyone,

Le 18/10/2011 00:36, exarkun at twistedmatrix.com a écrit :
> On 09:21 pm, barry at python.org wrote:
>> Ideally, the tester would just be running the tests that the package 
>> author itself sets up.  I still think `python setup.py test` should
>> be the cli for that.
> 
> One thing that turns me off of this approach is that various tools have 
> taken to executing setup.py in all kinds of strange contexts, so it's 
> not at all clear what expectations authors should have when trying to 
> make `python setup.py test` work.
> 
> What parts of the project under test will be importable?
What about all of them?  The distutils2 test command calls build and
adds the build dir to sys.path before running the tests (I’m going to
change that to call build_ext --inplace instead, to support extension
modules that are part of a package).  We’re also working on a patch so
that the PEP 376 dist-info directory is created before tests run, to
give tests access to the packaging.database functionality.  From a quick
glance at distribute, the setuptools test command calls the build and
egg_info commands (with build_ext -i) and puts the project directory on
sys.path.

> What kind of environment setup is `python setup.py test` responsible for?
I assume that by “environment” you mean executing commands to e.g. start
a daemon process that the tests need.  IMO, such setup belongs in the
tests’ __init__ module or setUp/setUpClass methods, but I don’t have
much experience with complex test environments; the hardest thing I’ve
done is probably starting a redis server, which is very easy :)

> Is `python setup.py test` supposed to work on a vanilla unpacked tarball,
> or is it expected to run only after `python setup.py install` has succeeded?
It should run from an uninstalled VCS checkout, from a unpacked sdist,
from an unpacked tarball produced by the VCS, etc.

> What if the test runner is part of the project under test?
Then it should be found.

> What if there is already an installed version of the project, different
> from the one being tested?
Doesn’t matter, as setuptools and distutils2 put the project directory
at the top of sys.path.

> What if there are dependencies needed before the tests can be run?
setuptools has a tests_require option to specify distributions to be
installed before running tests.  (Note that tox does not seem to honor
them.)  For distutils2 it’s still under discussion.

Cheers