Repository navigation
Speed up the test suite - #285
Merged
Merged
Conversation
Thirty-eight test classes each reloaded both fixtures (0.8s apiece), and the saint search tests backfilled slugs and rebuilt the search index before every test. A test runner now does all of that once, after the test database is created, as the Dockerfile does for production. The day API sweep in test_errors covers one year instead of seven; the fasting snapshot already covers ten years of Day. The tests now take 13s instead of 87-102s. Building the test database, which loads the scriptures, still takes about 38s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The image's db.sqlite3 already has the migrations applied, including the scripture loads that took about 38s of every run, and the fixtures, slugs and search index loaded. The test runner now copies it into place as the test database and keeps it, so a Docker test run takes 14s instead of 57s. Without a current db.sqlite3 it builds from scratch and loads the data once, as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
brianglass
changed the title
parse_usfx went through pulldom, which builds a DOM node and attribute objects for every element and text run, and the migrations inserted the 171,116 verses one row at a time. The same parsing logic now runs from expat callbacks, and the verses go in with bulk_create. Loading the scriptures takes 6.4s instead of 31.2s, which every image build and every fresh test database pays; the verse table comes out byte for byte the same. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
It passed parse_usfx a language argument it never accepted, so it failed as soon as it ran. The scripture migrations load the Bibles instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merged
brianglass
added a commit
that referenced
this pull request
Nov 7, 2026
* Load the test data once per run, and shorten the API sweep Thirty-eight test classes each reloaded both fixtures (0.8s apiece), and the saint search tests backfilled slugs and rebuilt the search index before every test. A test runner now does all of that once, after the test database is created, as the Dockerfile does for production. The day API sweep in test_errors covers one year instead of seven; the fasting snapshot already covers ten years of Day. The tests now take 13s instead of 87-102s. Building the test database, which loads the scriptures, still takes about 38s. * Start the tests from the database the Docker image built The image's db.sqlite3 already has the migrations applied, including the scripture loads that took about 38s of every run, and the fixtures, slugs and search index loaded. The test runner now copies it into place as the test database and keeps it, so a Docker test run takes 14s instead of 57s. Without a current db.sqlite3 it builds from scratch and loads the data once, as before. * Load the scriptures with expat and bulk_create parse_usfx went through pulldom, which builds a DOM node and attribute objects for every element and text run, and the migrations inserted the 171,116 verses one row at a time. The same parsing logic now runs from expat callbacks, and the verses go in with bulk_create. Loading the scriptures takes 6.4s instead of 31.2s, which every image build and every fresh test database pays; the verse table comes out byte for byte the same. * Remove the unused ingest_usfx command It passed parse_usfx a language argument it never accepted, so it failed as soon as it ran. The scripture migrations load the Bibles instead. --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The test suite took about two minutes a run, locally and in GitHub Actions. A Docker run now takes 14 seconds.
What changed.
db.sqlite3already has every migration applied, including the scripture loads, and the fixtures, slugs and search index loaded. A new test runner,orthocal.test_runner.FixtureRunner, copies it into place as the test database and keeps it, so nothing is rebuilt. It copies only adb.sqlite3newer than both fixtures; otherwise it builds the test database from scratch and loads the data once.calendarium.jsonandcommemorations.jsonthroughTestCase.fixtures, at 0.8s per load. In the image they're already in the database; without it, the runner loads them once. Each test still rolls back its own changes, and no test usesTransactionTestCase, which would empty the tables.commemorations/tests.pyandmcp_svc/tests/test_tools.pybackfilled slugs and normalized names and rebuilt the full-text index insetUp, before every test. That data is now in the database from the start.parse_usfxusedpulldom, which builds a DOM node and attribute objects for every element and text run, and the migrations inserted the 171,116 verses one row at a time. The same parsing logic now runs fromexpatcallbacks, and the migrations usebulk_create. Loading the scriptures takes 6.4s instead of 31.2s. Every image build pays this, in Cloud Build and in GitHub Actions. The verse table comes out the same: a checksum over every row matches before and after.DayAPITestCase.test_errorscalled the day API for every date from 2023 to 2029, 2,557 requests in 14s. It now covers 2027. The fasting snapshot test already builds every day for ten years.Timing (local, whole
docker compose run --rm tests):The tests themselves take 10–13s, down from 87–102s. A run that has to build the test database from scratch now takes 22s instead of about 57s.
All 309 tests pass. This PR is based on #284, which also edits
test_liturgics.py.🤖 Generated with Claude Code