There are main 3 goals for the first major release of sundae.js:
The original outline of the project was largely taken from processing.js's developer tools reference tester. However as the scope of my project expanded a similar change had to be reflected in the way the code was designed. In order to facilitate this change the old reference tester has to be ripped into key sections, The test building process has to be clearly defined:
- Select the tests
- Load the tests dependencies
- Build test div and canvases
- Load test into canvas
- Load know good into canvas
- Blur both canvases
- Pixel by pixel compare each canvas
- Generate test result into canvas
- Load next test
- Compile results
As the project expands a clearly defined programming interface is necessary to maintain workflow. This design needs to have scalability at the forefront of the decision making process. We know each test case should be treated as its own object, an example of what to expect would be: dependencies, known good, error message, test. Additional standards will be that tests will load into a canvas as will their respective last known good result, from there the rest of the test process is built in.
Define test case structure
The thought process behind this goal is to allow for an easy to implement and expandable way to get your test cases working with sundae as fast as possible. The goal is to use a JSON object structured by my API design to clearly define everything optional and required for each test. Further additions include characterize tests by a directory structure. An obvious skill gap of JSON methodology will need to be bridged, however the benefits will be far reaching.
That is everything set up for the 0.4 release of sundae.js!