Add client component testing framework and tests

[mikiher]

I took a stab at adding client component testing.

My goals were, roughly:

1. to be able to write single component tests easily (like unit tests on the server)
2. to be able to run the tests easily and quickly (like unit tests on the server)
3. to not have to work hard at setting up the test environment

I tried a few options. I must say that in most options I tried, it has been quite difficult to even reach something that actually works in our current Nuxt2+Vue2 environment.

I eventually settled on Cypress (which was already tried in #2240), but taking a very different approach from that PR, which tried to introduce complex e2e test scenarios. The reasons for picking Cypress, in a nutshell, were:

• Cypress supports Nuxt2+Vue2 component testing out-of-the-box (though support is claimed to be alpha, it works quite well). It's really the only framework that does that.
• It is based on mocha, chai, and sinon, like our server unit tests.
• It provides easy, useful, and readable API for testing, which
  • lets you mount a component in isolation
  • allows for querying and taking actions on the mounted component DOM structure
  • has all the richness of chai, chai-sinon, and chai-jquery assertions
• As opposed to most other testing frameworks, it runs tests inside a browser (other framworks run tests on a browser-less DOM, like jsdom).
  • This allows testing for things like layout, which aren't supported in jsdom.
  • It also allows for visual testing (actually seeing the components and how various properties and actions modify them), which is a really nice feature.

Obviously, there are also some caveats:

• Nuxt2 support is still in alpha, although it seems already quite stable
• Support for Nuxt-specific behaviours is still quite minimal. For example:
  • It doesn't recognize Nuxt-specific components like nuxt-link
  • It doesn't support Nuxt's auto-import feature for components, so you need to work-around this
  • It doesn't automatically load Nuxt plugins (and so you need to stub things like $store, $toast, $axios, etc, but these are things that probably makes sense to mock in component tests anyway)

But, all-in-all, I think it's a quite reasonable testing framework for component-testing (and, as I mentioned above, really the only working one).

In this PR:

• I added Cypress to the dev dependencies in the client package.json
• I added the required Cypress configuration and support files
• I wrote tests for a couple of components:
  • NarratorCard.vue
  • AuthorCard.vue
• I added some npm scripts on the client:
  • npm test - runs the tests (command-line, suitable for Github Actions)
  • npm run test-visually - opens and runs the tests on Chrome (very nice! try it out)

Please let me know what you think.

[mikiher]

A couple of additional changes:

• Fixed a small bug in the AuthorCard test
• Made some useful plugins available to all mounted components (now they don't need to be stubbed):
  • $constants
  • $strings
  • utility functions in utils.js and init.client.js
• Added another component test for LazySeriesCard (maybe slighly more complex than the previous ones).

[mikiher]

OK, another couple of changes (some discussed over discord yesterday):

• Fixed all test element ids to camelCase
• Changed test id attribute to cy-id (since id has to be unique across the document, but cy-id doesn't)
• Modified cy.get() command so it translates &id to [cy-id="id"] (this is just a useful shortcut)
• Made the LazySeriesCard test load book_placeholder.jpg in advance so it's available to all tests in the browser cache.

Please let me know if you have any additional comments.

[advplyr]

What do you think about moving the tests into a separate folder? I would prefer that if there isn't some specific reason to keep them together.

[mikiher]

Will do.

…

On Tue, Apr 30, 2024, 00:28 advplyr ***@***.***> wrote: What do you think about moving the tests into a separate folder? I would prefer that if there isn't some specific reason to keep them together. — Reply to this email directly, view it on GitHub <#2853 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFMDFVWV5M6V7ID67M4IC7DY723Q5AVCNFSM6AAAAABGIGDPVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBTG4YDQMBXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mikiher]

I moved the tests to a separate directory.

[mikiher]

Also, can you please share your setup for auto-formatting/linting in vs code, so that I replicate them in my dev setup?
It's really a waste of your time to commit formatting fixes.
Can we somehow make this part of the .vscode configuration files?

[nichwall]

I think it's just using prettier (auto formatting happens on my machine in the dev container and I never set it up)

[mikiher]

The devcontainer.json setup does not include Prettier, so if it's there, you probably installed it yourself (the only two extensions included in the devcontainer setup are eslint and vetur).

In any case, that's not relevant to me, as I'm not running vs code in a devcontainer. I'm running it directly in Winodws 11.

I suspect that even if you have the right extensions installed (and I'm not sure I do), the workspace settings in .vscode/settings.json are not covering all the required settings.

[advplyr]

Great, thanks! I don't use the devcontainer either. I think the settings is missing somethings I've been meaning to look at updating. The PR #2183 is helpful for this. The number of files that prettier formatter was changing will take hours to go through so I haven't gotten to it yet

[advplyr]

I just committed an update using @ahobsonsayers suggested changes in #2183 minus the formatter. cb1ebd4

A lot of files will have formatting changes for a bit but this should get us on the same track.