Hi Lee, On Thu, 20 Jun 2013, Lee Kamentsky wrote:
> On Thu, Jun 20, 2013 at 12:27 PM, Curtis Rueden <ctrue...@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 _______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
