On Mon, Oct 19, 2009 at 6:55 PM, SirVer <sirver@gmx.de> wrote:

Hi,

I have something of a lot of importance to mention. We should start to
separate our tests into unit and integration tests. For what reason?
The 40 tests need 3.256 seconds on my box to run; that's approximately
the time it takes to compile the opencv module here. So compiling +
tests = 2 * compiling. That's still acceptable, but 40 tests is
nothing. 400 tests will need 30 seconds which is too much to run after
each edit.

The main thing I think is to be careful with images. The slowest one by far now are the tests for lpi_filter, because they do a lot of things with a *large* image.

This is why I originally put my test images for io under io/tests. I thought data_dir should only contain images for examples, useful for users. Images for testing algorithms can often be small. For the color conversion I now use images of size (4, 2, 3), which means they take no time at all.

But that is was unittests are for. The reason why I come up
with this now is that it is important to make this separation while it
is still easy and possible. The best way is to group tests into many
groups ('opencv', 'fast', 'slow', 'need_camera').

What is lacking when you apply decorators like @opencv_skip and @slow? Note also that if you run nosetests from some folder you run only tests in subfolders. This is a natural separation already.

A short blog post
concerning this is:

http://beust.com/weblog/archives/000319.html

That's mostly semantics.

I have no idea how to achieve this with pynose in a simple way
though,

Once again: I think scikit_image will grow fast and therefore test
will grow fast. Users will stop running the tests if they take to
long. Too long for an interactive coding session is > 10s .

True. The @slow decorator should take care of this. What is the approximate limit again when it should be used?

Cheers,
Ralf

Cheers,
Holger