Style Guide: Tests
- We use
numpy.testingmodule) to write test cases for MDAnalysis.
Do not use anything from
numpy.testingthat depends on
- The testsuite follows the same directory structure as the package.
This style guide is meant to be concise and allow developers to quickly learn which constructs to use and which ones to avoid. The rationale for these choices is discussed in issue #1444.
assertstatements for comparing single values. E.g., to check the length of an iterable
assert len(foo) == expected_length
To check equality for a single value up to a certain precision, use
numpy.testing. Do not manually round off the value and use plain assert statements. Do not use
To compare an iterable, use
numpy.testing. Do not iterate over and compare every single value.
To compare an iterable up to a certain precision, use
Do not use
numpy.testingto compare array/array-like data structures. Instead, use
Use classes to group tests if it makes sense (e.g., if the test class will be inherited by another test class and the code can be reused). We prefer subclassing over parametrizing classes (for examples, have a look at the topology module).
For everything else, use plain functions.
- To check for a particular exception, use the
Do not use
Do not use the
- To check for a particular warning, use the
- To mark an expected failure, use
- To manually fail a test, make a call to
Temporary files and directories
Use pytest's inbuilt
- To create a temp file
temporary_file = str(tmpdir.join('test.pdb'))
- To use a temp directory as the working directory, use
- To skip tests based on a condition, use
- To skip a test if a module is not available for importing, use
Testing the same function with different inputs
- Use the
pytest.mark.parametrizedecorator to test the same function for different inputs
- Use fixtures as much as possible to reuse "resources" between test methods/functions (example: universe fixture). The rule of thumb is to use the largest possible scope for the fixture.