Improve testing

[nicksellen]

This PR is for https://community.karrot.world/t/nlnet-responsiblities/892 Add frontend integration tests and aim for 75% test coverage task.

This is a change of testing approach, loosely based on Kent C. Dodds blog post Write tests. Not too many. Mostly integration..

The premise is that the tooling is good enough to write integration tests that run reliably, and are easy enough to write. The older paradigm of a bazillion unit tests was partly based on it being difficult to write integration tests.

So, the new approach is:

• use https://testing-library.com which encourages higher level testing from the user perspective
• two types of tests:
  • page-level tests (e.g. testing stuff in src/*/pages/*.vue) that load the page component but not the router
  • App tests, that load the root App component and the router
• use the new mockBackend which mocks at the axios-layer, for all tests that need it

[codecov]

Codecov Report

Merging #2536 (6e5227d) into add/more-vue-query (e08d4a8) will increase coverage by 33.98%.
The diff coverage is 98.60%.

@@                   Coverage Diff                   @@
##           add/more-vue-query    #2536       +/-   ##
=======================================================
+ Coverage               26.15%   60.13%   +33.98%     
=======================================================
  Files                     210      181       -29     
  Lines                    4252     3946      -306     
  Branches                  657      715       +58     
=======================================================
+ Hits                     1112     2373     +1261     
+ Misses                   3140     1573     -1567     

Impacted Files	Coverage Δ
.storybook/main.js	17.64% <ø> (ø)
src/base/pages/Landing.vue	100.00% <ø> (ø)
src/base/services.js	64.15% <0.00%> (+58.38%)	⬆️
src/groupInfo/pages/GroupGallery.vue	100.00% <ø> (ø)
src/groupInfo/pages/GroupPreview.vue	100.00% <ø> (ø)
src/offers/pages/GroupOffers.vue	100.00% <ø> (ø)
src/boot/performance.js	20.68% <66.66%> (ø)
src/utils/datastore/helpers.js	61.84% <92.30%> (+21.21%)	⬆️
test/mockBackend/mockAxios.js	98.86% <98.86%> (ø)
.storybook/preview.js	86.66% <100.00%> (ø)
... and 195 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[tiltec]

Regarding integration tests, I wonder if we should add the Cypress test framework? It seems to be recommended by Quasar: https://github.com/quasarframework/quasar-testing/blob/dev/packages/e2e-cypress/README.md

EDIT: People on HN seem to recommend Playwright over Cypress: https://news.ycombinator.com/item?id=30083042

[nicksellen]

My current sense is to try and create integration tests that are not end to end tests.

So, this sense of them from Kent C Dodds:

The e2e testing tools are quite heavy. So, one idea, which I didn't yet explore further is something along the lines of:

• use our existing jest-based setup
• load the entire app, complete with a real store
• mock at the API/REST-layer only

The sense of the goals I have here are:

• be able to test how the an assemble of components behaves in the presence of the store
• be the main default way to write a test for a feature
• hit the sweet spot between a tool that actually runs a browser and clicks around (slow, flakey) and complex components that have a mountain of barely functioning mocks surrounding it (complex, fragile, not testing a lot)

It might be that:

• loading the entire app this way is too hard, but maybe page-level components would still be useful integration tests
• it reveals how entangled everything is, so it can be best-effort, and use the knowledge to inform the data layer explorations
• we need a quite complex mock API (I remember discussing/debating this before, at some point it feels like implementing a whole new backend :) )

However, a bunch of things push integration tests more into e2e tooling. quasar-testing seems still being upgraded to v2, and lists unit testing (with jest) and e2e testing (with cypress), so the type of tests I'm talking about may not be very well supported by the tooling.