[old][SPIKE][DO NOT MERGE] Investigate using Jest for unit testing

[vanitabarrett]

Investigation into #2559

What

Spike to see how we can add unit tests for our component JavaScript. This spike explores using tooling we already have (i.e: Jest) rather than introducing a new library.

Findings / Thoughts

• Jest has built-in support for ESM - however, it seems to rely on using the .mjs file extension (among other things) which complicates the current testing we have. You can also use Babel (Jest ships with babel-jest) to compile code, which is the approach used in this spike.
• Because we're initialising the component in each test, that gives us greater control over what it's initialised with. This lets us test different scenarios, which is a bit more tricky with our current test setup as it relies on the review app.
• A lot of our component JS does some sort of DOM manipulation, e.g: adding/removing attributes, creating new elements and appending them. It can be quite lengthy testing that, as we have to set up the right HTML elements in the DOM before running the test (as seen in this spike). An alternative approach might be making more use of mocks and spies to ensure the right things are being called with the right arguments, rather than actually checking the DOM.
• I'm not sure how well this approach works for something like the accordion JS at the moment, where a lot of functions create HTML elements but don't append them to the DOM, and probably also rely on previous execution of other functions (i.e: we're not passing things through as arguments to functions, but using globals). We'd probably want to do some refactoring before adding unit tests here.
• I think there's also a bit of overlap now between these tests and the other tests we have in place, so we would probably want to consider what exactly we want to use unit tests vs our existing JavaScript tests for.

[vanitabarrett]

Update:

I've pulled in some commits from the i18n spike to see how this testing strategy fits with that. Broadly it seems to work fine - we can pull in and set translations within unit tests so have control over testing how component JS handles different translations. We can also add tests for the i18n function itself (note: this has been tested with the previous iteration of the i18n function, not the new version using the Singleton pattern).

Adding any kind of translations to our example app will require us to change existing tests that require the review app as the text will be different. Probably another reason why having tests based on our review app is perhaps not ideal.

[vanitabarrett]

This spike is superseded by #2680 which works with the latest (and hopefully more "stable" i18n approach) and the new .mjs component JS which affects how unit testing is set up.