Test coverage
joaodasilva opened this issue · comments
The project doesn't have any test coverage so far, other than checking out the examples.
Issues like #34 require changing a large number of places, and this only scales when test coverage to confirm that everything is still working as expected.
The idea is to build a test runner that runs on Window.js itself:
- it spawns subprocesses to run individual test suites
- all documented APIs should have test coverage, in all their variants, including invalid invocations and thrown errors
- also have some pixel-diff tests to verify that rendering is working as expected.
I wrote a little test suite which is meant to be self contained, zero deps, isomorphic, portable etc
It might be one of the easier test suites to get working outside a regular browser or node context..
@sc0ttj thanks for the hint! Zero deps is very appealing :-)
I'm building a custom test runner first, to make use of subprocesses in Window.js: each test suite runs in its own process, and N suites run in parallel at a time (N == number of parallel threads supported by the current machine).
The more important API to test right now is the Canvas API, and the tests will be mostly pixel diff tests: does the image rendered match an expected image. Does tea support that?
de115f7 added a test runner and initial test coverage for the File API, Process API and some globals.
6a09576 enabled running those tests in the build workflows.
The next tests will cover the Window API, and the runner/test library should also support pixel diff tests to test the output of the Canvas API via screenshots.