Epic: DOM-to-database testing

[praseodym]

Test DOM-to-database, i.e. browser->frontend->backend->database.

• [x] #172
• [x] #177
• [x] #189
• [x] #154
• [x] #218
• [x] #217
• [x] #216
• [x] #318
• Decide on locator strategy and update code and tests if needed

For frontend+MSW tests, there's also #62 (Playwright tests for clicking through the front-end with MSW).

[praseodym]

I think being able to serve the frontend through the backend (#63) will also be helpful here, so we can do the Playwright test using the a fully built frontend instead of a dev server. This doesn't have to depend on the full scope of #63, though.

[jschuurk-kr]

References for the pipeline task:

• reusing workflows: dependencies as reusable workflows, called as jobs in another workflow.
• uploading and downloading artifacts
• https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow

[jschuurk-kr]

Using artifacts from the backend workflow for the dom-to-db tests:

• artifacts: backend/target/debug/api and backend/target/debug/db.sqlite
• dom-to-db tests need to do their own test data setup, either the files in backend/fixtures or a different set of test data specific to the dom-to-db tests

It might be worth it to have data files that are read by the tests and are used to generate the .sql files. Once we have the functionality to import that data as EML files, we can migrate to those where sensible.

[praseodym]

References for the pipeline task: [..]

I think it might be easiest to integrate building and testing the backend and frontend and executing the DOM-to-database tests as multiple jobs in a single workflow. This makes it easy to specify job dependencies while avoiding redoing work.

[praseodym]

Using artifacts from the backend workflow for the dom-to-db tests:

• artifacts: backend/target/debug/api and backend/target/debug/db.sqlite

I think we'll want to use a release build and not a debug build. Also, db.sqlite is created when starting the API server, so we don't need to ship it as an artefact.

• dom-to-db tests need to do their own test data setup, either the files in backend/fixtures or a different set of test data specific to the dom-to-db tests

If we want to ship fixtures with the API server, #154 was created to simplify this.

It might be worth it to have data files that are read by the tests and are used to generate the .sql files. Once we have the functionality to import that data as EML files, we can migrate to those where sensible.

Sharing fixtures between frontend and backend, including generating SQL files, was considered in #109 but turned out to be a rabbit hole we decided to avoid. You'd have to transform the JSON format from an API response into rows as stored in the database, redoing all the transformations done by the API server.

[jschuurk-kr]

Sharing fixtures between frontend and backend, including generating SQL files, was considered in #109 but turned out to be a rabbit hole we decided to avoid. You'd have to transform the JSON format from an API response into rows as stored in the database, redoing all the transformations done by the API server.

I'm not thinking about sharing fixtures between frontend and backend. I'm looking for a way to make the SQL files easily parsable for the dom-to-db tests.

That does assume we have at least one test that either:

• needs to have data it can't get from the UI or from an API call, or
• wants to check what's in the UI against what was inserted into the database.

And even then, it might still be simpler to parse the SQL file in the test code, than to start generating the SQL files based on e.g. json.

Also, checking against the fixtures is checking against the database in its 'initial' state. That might not be the state of data when a particular test runs.

So yeah, let's wait for an actual problem to appear, so we solve the right one.

[praseodym]

I think being able to serve the frontend through the backend (#63) will also be helpful here, so we can do the Playwright test using the a fully built frontend instead of a dev server. This doesn't have to depend on the full scope of #63, though.

With #175 you should be able to do something like:

Frontend build job:

cd frontend
npm ci
npm run build
# upload `dist` directory as job artifact

Backend build job:

cd backend
cargo build --release
# upload `target/release/api` binary as job artifact

Then run in the Playwright job:

# download and unpack frontend and backend artifacts to current directory
./api --frontend-dist=dist
# run Playwright tests against http://localhost:8080/

[jschuurk-kr]

Idea for the playwright config:

• when not running in CI: build frontend and backend, then run tests (ToDo: check if that doesn't take too long for the value it brings)
• when running in CI: use builds from frontend and backend jobs

Note: at least in the pipeline we also need to insert the data into the database. (While running locally, this can be the user's problem for now.) So related to #154.

[praseodym]

@jschuurk-kr all linked issues are done, can we close this epic? 😃