Write some tests

[stevenday]

In some kind of order of priority:

• A general 'does it work' acceptance test, driving the main library through JSDOM, and/or driving the whole demo app through a headless browser.
• Unit tests for data parsing and sanitising data
• Unit tests for template rendering
• Unit tests for D3 rendering

[kd-ods]

@codemacabre - as we approach sprint 2... can I usefully produce some minimal BODS 0.4-like JSON which should be parse-able and renderable by the visualiser? This relates to the data requirements of the visualiser, that it should do its best to visualise data, even if it is not valid.

[codemacabre]

Thank you @kd-ods. Yes, please do produce some minimal JSON. The more example data to test this against, the better!

[kd-ods]

Myles, as I started looking at this, it was obvious that we need to work on the Spec in parallel. So I've started that here. I'd like to check my thinking with you today.

[codemacabre]

This is proving to be a complicated one. JSDOM alone doesn't have the testing features we need, so I've evaluated a considerable number of other testing frameworks and libraries to see which might be most suitable.

One hurdle: as we use ES Modules (i.e. import and export statements) throughout the codebase, most libraries require updating the package.json along with webpack configurations to also support ES Modules.

Unfortunately, my library of choice, Jest, only has experimental support for ESM and my experiments with it proved to have major issues, particularly when using alongside D3 libraries.

After trying a number of other options, I've opted for Vitest, which is a more modern framework, designed for Vite rather than webpack, but can be made to work without the Vite requirement. (On a side note, it may be worthwhile updating this to use Vite instead of webpack at some point in the future). Fortunately, it supports Jest syntax so the tests I wrote while experimenting with Jest still work.

Another hurdle: These frameworks and libraries are great for unit testing, but to perform end-to-end (acceptance) testing, we'd need another framework. I've tried testing the draw() function using Vitest's mocked browser APIs (i.e. JSDOM and happy-dom) and they aren't sophisticated enough to mock the complexities of rendering an SVG.

So, I'm left with a choice:

1. Look for an additional framework to perform a small number of end-to-end tests (such as Cypress, Puppeteer, Playwright). This will introduce a bit of overhead in our dev dependencies.
2. Try Vitest's experimental browser mode which optionally uses Playwright under the hood. Initial experiments haven't been very successful.
3. Don't write any end-to-end tests and instead write more unit tests to cover as many aspects of the basic functionality as possible.

[codemacabre]

Since the above comment, I've got Jest working together with Puppeteer and I'm struggling to find a decent way to test the SVG output. It's making me sway towards choice 3, as there doesn't seem to be much precedent for testing that the SVGs have rendered correctly.

A couple of options occur to me:

• Checking the SVG for expected text content (Cypress can do this with the .contains method)
• Using snapshot testing to perform a visual diff between screenshots of the SVG output (most end-to-end testing frameworks can do this)

But neither of them feel like particularly good means to assert that an SVG has actually rendered correctly and are fairly blunt instruments. I'd probably prefer to focus on writing end-to-end tests to cover more of the logic.