[ImageJ-devel] imglib2-io as a test phase dependency of imglib-algorithms

[Johannes Schindelin]

Hi Lee,

On Thu, 20 Jun 2013, Lee Kamentsky wrote:

> On Thu, Jun 20, 2013 at 12:27 PM, Curtis Rueden <ctrueden at wisc.edu> wrote:
> 
> > I'm thinking of storing very small .tifs as resources
> >
> > 2) Rather than TIFFs, you can use .fake file paths for testing without
> > needing to commit any actual images to the repository. The .fake "file
> > format" was invented for exactly such a purpose, to make unit testing
> > easy.  The only downside is that you can't precisely control the pixel
> > contents, but for unit tests you rarely need to. Rather, you typically
> > want the test to verify that it processes data in various structures
> > properly (RGB vs.  grayscale, huge plane sizes, etc.).
> >
> > Would that work for you?
> >
> For the pyramids, I want to compare the output of the C reference
> implementation against my own. That means that I have to generate the
> results using an image with known contents. Johannes suggested
> generating test images. In CellProfiler, I often do similar - use a
> pseudo-random number generator with fixed seed to generate the same
> image every time. I was planning to include the reference implementation
> outputs (there are six different variants = 6 outputs), but perhaps it's
> enough to randomly sample the values at a handful of coordinates and
> check those instead of checking the entire image.
> 
> For CP unit tests, we have a standard set of images that we use throughout
> the tests (stored in an svn repository, not GIT). ImageJ has those example
> images and maybe those are enough for testing.

Well, with Maven it would be easy enough to have a profile that drags in
certain dependencies only conditionally. That way, we could have a
repository that is meant to bloat. If the tests now call
"Assume.assumeTrue(file.exists())" before using "file", we're all set.

Ciao,
Dscho