Testing and Linting

Introduction

Our goal is to have readable and consistent code, our definition of that is to respect PEP 8 guidelines. The application of the guidelines can be ignored in especially one case, which is also specified in PEP 8:

When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.

Furthermore, to have consistent imports (e.g. relative references, line wrapping) we sort them using isort, as configured in the setup.cfg.

Further more, in order to catch bugs earlier we employ unit tests. Currently, the test are handled using djangos test framework.

Attention

Please quality-check all your contributions before submitting using the provided script!

Checking your code

For convenience, a lint.py script is located in /scripts/. It does no automatic fixing with isort by default. To invoke the script, simply run

$ python3 scripts/lint.py
$ scripts/lint.py # Alternative execution as a binary

By adding the --fix flag, this tool tries to fix your isort issues where possible.

Furthermore, it can be run as a git pre-commit hook like so:

$ ln scripts/pre-commit-hook.sh .git/hooks/pre-commit
$ chmod +x .git/hooks/pre-commit

Individual tests

Individual tests can be run using the --checks parameter. Multiple checks can be separated by spaces.

$ ./lint.py --checks django
Will run django
running django...

System check identified no issues (0 silenced).
=> passed

Summary:      passed
django                passed

$ ./lint.py --checks django isort
System check identified no issues (0 silenced).
Will run django, isort
running django...

=> passed

running isort...

=> passed

passed
django        passed
isort         passed

Unit Tests

Note

The unit tests are not called from the lint.py!

All of the tests are located in in src/tests/ and are roughly split by apps and optionally, to improve on readability, a bit by what they are testing.

Testing should both test if all parts are working overall, but also for specific edge cases.

The GitHub Actions CI runs the tests from python 3.6 to 3.9. Tests can be run on your your local machine by running

$ python manage.py test tests

If you are interested in coverage reports, prepend coverage run and use coverage report afterwards like so:

$ coverage run --source='.' manage.py test tests
$ coverage report --sort Cover # Sort files by coverage

For futher information, refer to the coverage.py docs.

Overall it would be nice if new features and bug fixes add one or many related unit tests, however this usually won’t be merge blocking.

Checking manually

To check our code against PEP 8 conformity, we use flake8. To check your code, execute the following command from within the src folder:

$ flake8 . --show-source

If there are any violations, those will be listed in combination with their location.

Check for import errors with the isort command like this:

$ isort --color --check -q .

Again, no output is a good thing as everything is fine. isort, unlike flake8 can also fix it up for you:

$ isort --interactive .

Note

If you just want to have it fixed without approval of every change, leave out the --interactive

These tools are also used in our CI, checking every commit and PR for conformity.