# Testing overview How DevPlace verifies itself: an end-to-end browser suite, in-process unit tests, and a load-testing rig, all driven through the project `Makefile`, measured for coverage, and promoted through automated DTAP streets. See also [Test framework and rules](/docs/testing-framework.html), [Load testing with Locust](/docs/testing-locust.html), [Running tests via make](/docs/testing-make.html), and [Coverage and CI/CD](/docs/testing-cicd.html). ## Two layers, one suite The `tests/` directory holds the correctness suite: over 600 tests across 48 `test_*.py` files. Two styles live side by side and run under the same `pytest` invocation: - **End-to-end (Playwright).** A real Chromium browser drives a real Uvicorn server. These cover anything a user sees or clicks: rendering, forms, navigation, modals, and JavaScript behavior. - **In-process unit and API tests.** A FastAPI `TestClient` (or direct `asyncio` calls) exercises routers, data helpers, and JSON responses without a browser, for logic that has no UI surface. Both styles share one fixture stack and one ephemeral SQLite database, so a single `make test` runs everything. ## The load layer `locustfile.py` is a separate concern: it does not assert correctness, it measures throughput and latency under concurrent traffic. It spins up its own server on its own port against a throwaway database, then floods it with simulated users. Run it from `make locust` (interactive web UI) or `make locust-headless` (CI-style, writes an HTML report). See [Load testing with Locust](/docs/testing-locust.html). ## Coverage and continuous delivery Every run is measured for coverage (`coverage.py` over the `devplacepy` package, including the Uvicorn subprocess that the browser tests drive), and the suite is wired into automated DTAP streets. `.gitea/workflows/test.yaml` runs the full suite under coverage on every push and pull request to `master`, publishes the coverage HTML as an artifact, and uploads failure screenshots; only commits that pass that gate are promoted from `master` to the `production` branch. The full coverage configuration, the Gitea pipeline steps, and the Development, Test, Acceptance, and Production streets are documented in [Coverage and CI/CD](/docs/testing-cicd.html). ## The cardinal rule **Every user-facing feature requires an end-to-end Playwright test.** A JSON endpoint or data helper may be covered by an in-process test alone, but anything rendered in the browser must be exercised through the browser. A feature is not complete until its E2E test passes. The framework conventions that make these tests reliable are documented in [Test framework and rules](/docs/testing-framework.html).