Skip to content

Testing

Marco Rosa edited this page Nov 14, 2023 · 4 revisions

Testing has been introduced for the GitScanner, FileScanner, GitFileScanner, GitPRScanner, Client, PgClient, and SqliteClient.

All the tests are contained in the tests/ directory, with the different types of tests in the relative folder.

Tests can be run either with unittest or pytest.

python -m unittest
# or
pytest

Tests can be also run individually through the command:

# run all tests from a directory
pytest tests/unit_tests

# run all tests from a file
pytest tests/unit_tests/test_scans.py

# run one specific test case
pytest tests/unit_tests/test_scans.py -k test_analyze_discoveries

​Requirements

Testing the package requires the installation of the libraries in tests/tests-requirements.txt

pip install -r tests/tests-requirements.txt

Some tests require authentication to github.com, so export a GitHub personal access token as an environment variable called GIT_TOKEN before running them.

export GIT_TOKEN=ghp_xxxxxxxxxxxxx

Types of tests

Unit tests

Unit tests are self-contained tests that test the functionality of one single method or module, isolating it from dependencies. These tests are really fast to run and can potentially be started after every file save. They involve mocking the dependencies through unittest.mock

Integration tests

Integration tests test the interaction between some of the functions or modules of the package. They are fairly quick to run, usually taking a couple of seconds to run. They can be run at every commit. It requires mocking some dependencies, and using some real-world data.

Functional tests

Functional tests test a slice of the application, from start to finish, without mocking. These are the most powerful tests to check that the app is running correctly in the big picture, as it mirrors real-world behavior. For this, they are quite slow to run, taking over 10 seconds to run. They can be run before merging a PR to check that everything is working successfully. Functional tests for postgres have the assumption that an initialized test database is already present, with its access credentials stored in a .env file in the tests/ folder.