Skip to content

Testing automation roadmap: CI, coverage, and the path beyond localhost tests #1278

@jonfroehlich

Description

@jonfroehlich

Summary

Tracking issue capturing a design discussion (June 2026) on maturing our testing setup. We started writing tests for the first time a few days ago (see #1267); the suite now lives in website/tests.py (~1,580 lines) with a solid two-tier design — SimpleTestCase + MagicMock for pure logic, DatabaseTestCase for the DB/view/template layer. The tests exist; nothing runs them automatically.

The core gap

We auto-deploy master to the test server on every push:

push to master → live on makeabilitylab-test.cs.washington.edu, with no checks in between.

So the regression tests we just wrote only protect us if a contributor remembers to run manage.py test in the container before pushing. With rotating student contributors and push-to-deploy, that honor-system gate is exactly what continuous integration (CI) removes.

Mechanics / cost (for the record)

  • GitHub Actions is free and unlimited for public repos (this repo is public). No billing, no minute caps. A run of our suite is ~1–3 min.
  • A failing test is a signal, not a gate: it shows a red ✗ on the commit and emails the author. It does not block, revert, or alter pushed code. Merge-blocking only happens if we opt into branch protection later.

Prioritized roadmap

First PR

Items 1 + 2 + 3 shipped together in #1279 / PR #1280 (merged 2026-06-15) — CI now runs the suite on every push to master and every PR.

Remaining: item 7 (deferred) + optional hardening follow-ups — see the latest status comment. Roadmap items 1–6 are complete.

Related

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions