search

natcap / urban-online-workflow

This repository hosts the beta implementation of the Urban Online ES Workflow. The project is intended to give urban planners the ability to create and assess scenarios using InVEST Urban models.
1 stars 5 forks source link

Frontend testing #35

Closed davemfish closed 1 year ago

davemfish commented 2 years ago

This is one component of #8 . But I wanted a dedicated issue to record notes & discuss just this topic.

Test runners: Vitest has been much, much easier to setup than jest for this reason:

https://vitest.dev/guide/why.html#why-vitest

Using Vite dev server to transform your files during testing, enables the creation of a simple runner that doesn't need to deal with the complexity of transforming source files and can solely focus on providing the best DX during testing. A test runner that uses the same configuration of your App (through vite.config.js), sharing a common transformation pipeline during dev, build, and test time.

Test environment (virtual DOM) We need a virtual DOM in order to test & interact with our react components. jsdom is the most popular choice. happy-dom is an alternative. Most comparisons emphasize better performance (query time) for happy-dom. But happy-dom also seems to include more of the global browser APIs than jsdom (i.e. fetch), which means we have to do less mocking. That was nice for getting things setup. Ultimately we might not want to make real fetch calls during tests though. Anyway, these two are easy to switch in vite.config.js.

Utilities for querying & interacting with the DOM @testing-library/* still seems great for writing integration tests that exercise react components.

Special case of testing OpenLayers elements The map renders as a <canvas> element. So we can't interact with it using familiar DOM-interaction APIs (i.e. testing-library or user-event). Also the virtual DOMs require some extra configuration to support canvas. (jsdom can be configured with canvas, I'm not sure about happy-dom).

So it might make the most sense to test map interactions using a real browser controlled by puppeteer. If we do that, I don't think we need to think much about the canvas API, we just execute mouse events, etc.

davemfish commented 1 year ago

We added a minimal test suite in #38 , but I'll leave this open because we'll want to add test coverage.

davemfish commented 1 year ago

I think it might be a good time to add a batch of integration tests. There is now enough complexity in the UI, in terms of different pathways the user can take, that it will be a time-save during development to have tests covering those pathways. Up to now, I've basically been trying to manually test all the paths to make sure they work after adding a new feature.

davemfish commented 1 year ago

As of #115 we have some basic integration tests, and we have the infrastructure in place to continue to add tests as we develop. So I'll close this issue.