Improve Testing

[martinklepsch]

All of these packages should go through some basic testing before being published. I started a very simple approach in the testbed project but as @Deraen noted this is probably better be done as part of packaging within this repository.

[j1mr10rd4n]

Hi Martin,

I've created a test-externs branch with an idea for a testing strategy. It uses processing-js as an example because it was requested in #18 and also because processing-js has a comprehensive reference test suite.

This branch's build.boot introduces a test-externs task that processes the reference tests using the Google Closure Compiler with advanced-optimizations before running them against the processing-js library in a PhantomJS instance. There are a couple of extra details due to the way the reference tests are written (see list of steps further down) but this is illustrates the strategy. It could probably be used on other js libraries that have reasonable test suites.

As it stands, only the test code is processed by the google closure compiler. The processing-js library itself is linked as an external library in the test suite. I don't think the processing-js code is compatible with advanced-optimizations and would have to be included as a foreign-lib. The externs ensure that client code is compatible - this testing strategy has already highlighted an error and some omissions in the file pulled from quil/processing-js.

List of Steps

• Convert reference tests from .pde to .js. The reference tests are actually written in the Processing DSL. The test-externs task's first step is to use processing-js in a PhantomJS instance to Processing.compile() the reference tests to javascript. The javascript versions are written to files with proper goog.provide namespaces.
• Write a doo wrapper that requires the javascript reference test namespaces. The wrapper invokes code that will launch and monitor the test progress in a PhantomJS instance.
• Process the wrapper and reference tests through the google closure compiler with advanced optimizations and the package's externs file.
• Munge the test suite so that, for each reference test, the optimized code is injected in place of the standard code. Munge the list of tests to exclude any that we know will fail (see limitations below).
• Run the test suite and report.

Limitations / Further Work

• Because it's running in PhantomJS, only the 2D reference tests are exercised - could use a full browser (e.g.Firefox) instead of PhantomJS to include the 3D tests as well.
• Any code that declares its own classes in the Processing DSL, when compiled to javascript using Processing.compile() is implemented using dynamic class decorators like addMethod(). This means that the new method is declared using a string and the google closure compiler will not touch it. However the actual function call to the method will get munged. To fix this, the function name needs to be exported but this would be the author's responsibility or would require a change in the implementation of Processing.compile().
• Each javascript library will have its own testing strategy, so any automated externs tests would have to be bespoke.
• I'm fairly new to clojure so I'm sure my code can be improved!

I'd be very interested in your (and others') thoughts on this as a general approach to testing externs files. If you think this might be a useful package to add to cljsjs, I'd be happy to open a PR.