Toolchain for CI build & test for processing libraries

cansik

I currently work on some libraries for processing. The problem I encounter is, that it is not that easy to test the libraries on all different platforms (MacOS, Windows, Linux / RaspPi). So I thought, it would be nice to have an automated build and test system for libraries and sketches.

At the moment I am using Travis-CI for MacOS & Linux builds and AppVeyor for Windows builds. But I just build my library there and do not run any tests.

So it would be nice if there would be some scripts to install processing, add the already built library jar and run a test-sketch.

Does anyone already built something like that or would you like to use the toolchain too? This is is more a "should we / I do it" thread, where we can discuss to build such a toolchain.

What do you think about this idea?

jeremydouglass

@cansik -- Check out a recent discussion of automatic sketch testing:

• https://forum.processing.org/two/discussion/22869/pixel-test-for-simple-sketches-feedback-request

On the Processing.R mode project @gaocegege has been using this approach to incorporate end-to-end testing into the reference sketches and documentation, currently under active development. It works like this:

1. there are references pages for generating the documentation website -- https://github.com/gaocegege/Processing.R/tree/master/examples/reference/shape
2. these contain demo sketches (.pde -- in this case, .rpde) https://github.com/gaocegege/Processing.R/tree/master/examples/reference/shape/shape0
3. sketches point at a canonical output image (in the case of this mode a .yml file pointing at an official Processing image -- your library might have its own images) https://github.com/gaocegege/Processing.R/blob/master/examples/reference/shape/shape0/.test.yml
4. a test generator script generates a test for every sketch based on the sketch contents after the first frame of draw runs. https://github.com/gaocegege/Processing.R/blob/master/hack/generate-e2e-test.py
5. When a test runs, its added "saveFrame" output is compared to the output of the canonical image.
6. Tests are run locally or automatically from Github by both Travis-CI and Appveyor. Not sure what Raspberry PI would look like.

It looks to me like p5.js has something similar: https://github.com/processing/p5.js/blob/master/test/js/testRender.js