Hi Holger,
That's a good point.
On Mon, Oct 19, 2009 at 6:55 PM, SirVer
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