On Sat, Jul 5, 2008 at 7:09 PM, yahvuu <yahvuu@xxxxxxxxx> wrote: > here are some thoughts about a static test framework for gegl operations. > > * Functional Tests > These can be as simple as a set of files including a composition, > reference output and a test description. A perl/ruby script feeds the > composition through the gegl binary and compares the output with > reference data. Optionally some PNGs + HTML are created for visual inspection. GEGL should be capable of hosting it's own inspection framework for the generated images. Although not advertised as such, GeglBuffer serializes itself to a specified file format structure both for tiled and linear buffers for any format supported by babl. This is more or less what the current gallery is the start of. At the moment this gallery (sometimes augmented with development or developer specific examples) is one of the primary methods used to test for both functional as well as performance regressions. Comparisons are done manually though. Other better regression tests of a similar mind set are found for the functionality of GeglBuffer (this also being an ad-hoc test set, but at least comparisons and regressions are detected automatically. >snip< > Reference data is most easily created using Octave. Probably a 'make reference' target > will generate them from some ground truth m-files. This would mean reimplementing all the operations in octave as well. I do not see the purpose of this, once implemented as readable C source using floating point and having yielded a correct result, the correct result should be added to version control (but probably not the tarballs), to prevent future regressions. See also bug #427532 for other thoughts about testing of operaitons. http://bugzilla.gnome.org/show_bug.cgi?id=427532 > > * Unit Tests > Unit tests for operations are most comfortably expressed as functional tests. > However, there are some tests which are common for all/many operations: > - rendering must be independent of tile size The core implementation of operations should not be implemented using APIs that allow specifying the tile size, further regression tests of GeglBuffer should be added to the GeglBuffer test suite (which doesn't even need to make use of GeglNode/GeglOperation etc.) > - operations with spatial parameters should be scale invariance, i.e. > applying a operation on a downscaled composition using parameters which have been > downscaled by the same factor should give a good approximation of applying the > unscaled operation on the unscaled composition and downscaling afterwards. > - neutral settings One idea I've had in the past with regard to example compositions for the ops is adding the snippet of XML itself inside the .c file (maintaining the idea that for most ops a rather small .c file should be a selfcontained entity in the sourcetree). This embedded composition could have a small set of default images available for input. The resulting rendering could be displayed in the autogenerated operation reference. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
