Summary
The Django settings module used by the whole repo's test suite is currently buried inside the freetextresponse package (e.g. src/freetextresponse/tests/settings.py). This is misleading because it suggests the file belongs to one specific XBlock, when in reality it is shared across the entire repository.
Problem
- The test settings file is tied to the
freetextresponse package, but acts as a global test configuration.
- Any developer navigating to xblock-specific package test code will be confused to find repo-wide Django settings there.
- As more XBlocks are migrated into this repo, this inconsistency will become more confusing.
Proposed Solution
- Create a top-level
tests/ directory with an __init__.py.
- Move the settings file to
tests/settings.py.
- Update the
DJANGO_SETTINGS_MODULE reference in pyproject.toml (and anywhere else it is referenced) to point to tests.settings.
Context
Raised as a review comment in PR #36 during the freetextresponse XBlock migration. The PR author agreed it was a valid improvement but deferred it as a broader refactor beyond the migration PR's scope.
Reference: #36 (comment)
🤖 Generated with Claude Code
Summary
The Django settings module used by the whole repo's test suite is currently buried inside the
freetextresponsepackage (e.g.src/freetextresponse/tests/settings.py). This is misleading because it suggests the file belongs to one specific XBlock, when in reality it is shared across the entire repository.Problem
freetextresponsepackage, but acts as a global test configuration.Proposed Solution
tests/directory with an__init__.py.tests/settings.py.DJANGO_SETTINGS_MODULEreference inpyproject.toml(and anywhere else it is referenced) to point totests.settings.Context
Raised as a review comment in PR #36 during the
freetextresponseXBlock migration. The PR author agreed it was a valid improvement but deferred it as a broader refactor beyond the migration PR's scope.Reference: #36 (comment)
🤖 Generated with Claude Code