Testing¶
You should write tests as you write code – not as an afterthought once the project is complete.
See also
File naming and directory layout for tests
Write tests¶
Test code tends to be written once and only read when the test fails. As a result, test code tends to be poorly written, with a lot of copy-pasting between test methods, which makes intent unclear.
To write clear tests:
Test one scenario per test.
Name tests, fixtures, and mocks descriptively. Do not suffix them
1
,2
,3
, etc.Use pytest.mark.parametrize to test something with different inputs (like in OCDS Kit).
Use pytest.fixture to reuse test scaffolding (like in OCDS Merge or Kingfisher Colab).
Use unittest.TestCase to reuse testing logic, including:
Test methods (like ViewTests in Toucan)
Test scaffolding, using setUp() and tearDown()
Use subTest() from
unittest
(with pytest-subtests if usingpytest
) to reduce duplication (like in Pelican backend).
Note
There are important caveats to using pytest
with unittest
.
Attention
Remember to seal() a mock, to avoid unexpected behavior (for example, an attribute evaluating to True
because it returns a MagicMock
).
Run tests¶
For Django applications:
python manage.py test
Otherwise, pytest is preferred. For applications:
pip install -r requirements_dev.txt
pytest
For packages:
pip install .[test]
pytest