The assignment requires "a form of automated end-to-end testing (in practice: testing a longer sequence of interactions) and testing of the API" (Testing, development and quality control), and the fourth delivery is judged on testing "for typical and atypical use". The repository has component tests (Vitest) and API tests in `backend/src/server/`, but **no end-to-end test**: nothing drives the real application in a browser through a whole flow. Issue #76 asked for it, was closed, and its end-to-end item was never ticked ("needs a search page in the frontend", which now exists). ## What to do - **Playwright** (ready-made, drives a real browser) with `@axe-core/playwright` for the accessibility checks. `npm run e2e` runs it. - **Run it against any address.** By default it starts the backend and the frontend from the repository (the database must be running and seeded, as in the README). With `E2E_BASE_URL` it runs against an address that is already up, for example the virtual machine (`http://it2810-29.idi.ntnu.no/project2`), so the same tests check the real deployment. - **A longer user flow** (the point of "end-to-end"): search for a word, filter by apparatus and group and difficulty, sort, load more, open an element, go back and find the same result, clear the filters. Check the address, the results and the title at each step. - **Vault**: difficulty bands and sort by the D-score. - **Atypical use**: a wrong address (an apparatus or group that does not exist), a search with no result, a structure that fails to load (the request is made to fail), keyboard-only use of the filters and the sort, and the disabled group filter. - **Accessibility**: axe-core on the Elements page in its main states (filtered, a menu open, phone width, dark mode). - **API at the HTTP level**: a few requests to `/graphql` of the contract in `docs/API.md` (the filter and its error codes, `Apparatus.difficultyValues`, pagination), so the deployed server can be checked too. The detailed API tests stay in `backend/`. - **README**: how to install the browser, how to run it locally and against the virtual machine, and what it needs (seeded database). ## Done when - [ ] `npm run e2e` runs the tests in a real browser and passes against a seeded local database - [ ] The same tests can be run against another address with `E2E_BASE_URL` - [ ] At least one test is a longer sequence of interactions (search, filter, sort, load more, open an element, back) - [ ] Atypical use is tested: a wrong address, no results, a failing request, keyboard only - [ ] axe-core checks the page in its main states - [ ] The API is tested over HTTP, and the end-to-end test is not picked up by Vitest - [ ] The README says how to run it Depends on #135 (the filters and the sort on the Elements page).