Tooling

Static code analysis

This project uses the following tools for static code analysis:

black for code formatting
mypy for static type checking.
flake8 and pylint lint rules.
isort import sorting rules.

With the exception of mypy, all of these tools are configured to run in the CI pipeline.

Before commiting any changes to the repository, you can run static code analysis locally with:

make pre-commit

Optional

Ruff is also configured and can be used to replace most of the functionality of isort, flake8 and pylint within the project.

# Don't auto-fix issues
ruff check .

# Auto-fix issues
ruff check . --fix

The ruff linter can watch changes to a directory to alert you about lint rule violations on-the-fly:

ruff check . --watch

At this point in time, there are still some minor differences between black and ruff-format. Hence, it is not recommended to use the ruff-format with this repository.

Tests

All unit and integration tests are defined in ./tests. PyTest is used as the testing framework. Use the command below to run tests:

make python-test

### ----- OR ----- ###

python -m pytest .

Running the tests creates the build directory. The html test report can be viewed in any modern web browser by opening ./build/reports/code-coverage/index.html. All the tests should pass before merging code.

If the database is deployed with docker, then you must ensure that the database is visible to the host where the test command is being executed.

For example, if both the application and database are deployed in the same container network (e.g. after deploying with compose) then this can be achieved by executing test commands inside the backend application container:

docker exec -it ska-src-maltopuft-backend make python-test

or by updating the MALTOPUFT_DB_HOST environment variable to point to the IP address of the docker container, etc.