Add tests

[ROpdebee]

WIP, but sharing early, especially because this PR might grow to quite a large size.

Run tests using npx jest (TODO: add a package.json script).
Run tests using npm run test or npx jest or npm t.

The order of jobs in CI is currently a bit backwards (test -> build -> release makes little sense), but it works for now. Once tests that are ran in an actual browser are added, that order has to adapted.

[ROpdebee]

Every time I add tests to a module, I find stuff to refactor, so I'm half-tempted to merge this already and then work on tests and refactoring simultaneously in smaller PRs.

For example, the gmxhr refactoring (#69) already conflicts with the tests added here...

[kellnerd]

You don't have to create a separate branch for each change just for the purpose of easing reviews, do whatever feels most convenient for you. As long as there are separate commits for the different changes, I have no problem with a huge "refactoring & tests" PR. However, I think that I won't have time to review any PR in detail until the end of the week.

[ROpdebee]

I decided against refactoring qs/qsa/qsMaybe because both qs and qsa do useful things (asserting existence and converting to a real array, respectively). qsMaybe does nothing but wrap querySelector though, so it's a bit useless, but IMO it makes sense to keep it for the sake of consistency.

[ROpdebee]

I've done some experimentation, it appears that we'll run into quite a lot of problems if we try to test files containing JSX. We'd need to run them through babel first, but we can't do that with nativejsx currently. I don't feel like changing the way we handle JSX at the moment. I could write a babel plugin, but that's of course not going to be straightforward and I doubt it's worth it. On top of all that, the SCSS imports will be quite the challenge to deal with too.

Instead, I'd propose to split off the UI elements into separate TSX files whose sole responsibility will be UI stuff. I should be able to mock those imports in the unit tests, and besides, it's good software design to separate UI from logic anyway :)

[ROpdebee]

@kellnerd Marking this one as ready, as the lib and build stuff is fully covered with these tests, where possible*. I'm going to branch off to a separate PR to test the ECAU script source, since this one has already grown sufficiently.

Feel free to take a look through some of the changes on your own pace if you'd like, merging these changes isn't urgent. I'll likely go over the history once more myself soon-ish. Just let me know if you intend on reviewing or if I should just merge whenever I complete my double-checking pass. I'm fine with either. :)

*In terms of build, I'm only really testing the userscript metadata generator, not anything else. I'd rather not touch the build scripts too much, since I can't fully remember how they work 😅 Large swaths of its code are very difficult to properly test, and most (if not all) of that code is exercised by the CI build anyway. That of course doesn't verify that the scripts run properly when built, but I intend on adding real E2E browser tests at some point in the near future anyway, after unit testing the script code itself.

[kellnerd]

I will have a closer look over the weekend and might leave you some comments 😄

[kellnerd]

Looks good to me, I have run the tests locally with jest --verbose and jest --coverage. Lots of tests which should cover all the code in the src/lib if I can trust jest. I definitely would have been too lazy to write most of them ("this method is unlikely to break, that one too..." 😅).

P.S. Just to make it clear, while I know the theory about unit testing (in JS and Python), I have never actually written tests using a framework since my projects are usually to small for me to bother with, or die before they reach a state which would require proper testing framework.

[kellnerd]

I had just wondered what the origin of this directory could be, until I found out that I can get code coverage reports with jest --coverage.

[ROpdebee]

Yeah I should add a package script for coverage, maybe integrate some external service to visualise coverage after CI too.

[ROpdebee]

I definitely would have been too lazy to write most of them ("this method is unlikely to break, that one too..." 😅).

I always tell students that 100% code coverage doesn't mean much more than e.g. 90% code coverage. Your tests can achieve 100% coverage, but if you've got code like

function abs(x) { return x; }

and you only test abs(1), abs(0) and abs(100), you'll get 100% code coverage but your code will still do wrong things on abs(-1).

Nevertheless, 100% code coverage looks nice :) I use coverage mainly as a guidance to check what I might have forgotten to test, and if everything is green now in the coverage overview, and next week I make a change and all of a sudden it's not green anymore, I'll immediately know that certain parts need to be tested again. But I'm not going to go out of my way to cover some statement which is nearly impossible, I'll just add an /* istanbul ignore next */ comment before them (istanbul being the coverage provider) if I'm reasonably sure that 1) that statement is correct or 2) there will be another way to fail the deployment if the statement isn't.

Thanks for the review!