1
Testing and CI
Kemal Yaylali edited this page 2026-09-12 13:44:49 +01:00

Testing and CI

make test    # api (99 Python tests), ml, pipeline loader, web (49)
make lint    # ruff + mypy for the API, svelte-check for the front end

What is tested, and why there

Tests are concentrated where a mistake would be silent rather than loud.

  • api/tests/test_triage.py — the ranking arithmetic, as pure logic. This is the scientific claim the app makes, so it is tested without a database in the way. Includes the regression for components scoring evidence nobody looked up.
  • ml/tests/test_hpo.py — ontology propagation and information content, including a property test against a reference transitive closure. That test exists because a subtly wrong graph walk silently deleted 399 terms; see Gotchas.
  • pipeline/tests/test_load_db.py — the loader, against a real PostgreSQL. Idempotency is asserted directly: loading twice must not duplicate variants.
  • api/tests/test_security.py — the vcf_uri boundary.
  • api/tests/test_migrations.py — Alembic upgrade and downgrade against a live database.

Database tests use an embedded PostgreSQL (pgserver) locally and a service container in CI, because the schema is part of the behaviour and SQLite would not exercise it.

CI

Runs on pull requests and pushes to main:

Job Does
api ruff, mypy, pytest against a Postgres service
ml pytest
web npm run check, vitest, production build
pipeline loader tests against Postgres, then nextflow run main.nf -stub-run
terraform fmt -check and validate
images builds and pushes to Artifact Registry, main only

CI authenticates to Google Cloud with Workload Identity Federation. There is no service account key in the repository or in repository secrets.

A caution

CI does not run on branch pushes, only on pull requests and main. Work on a long-lived branch is therefore unverified by CI until the PR is opened — run make test && make lint locally.