-
Notifications
You must be signed in to change notification settings - Fork 0
Testing
Test are conducted with Pytest and Pytest-Django.
Required packages for unit testing are listed in the document 'requirements-testing.txt'. They could be installed separately using
pip install -r requirements-testing.txt
but as the testing is done inside a Docker container, building the projects also installs the testing requirements (use sudo, if needed):
docker-compose build
After the required packages are installed, the unit tests can be run with
docker-compose run qleader-web py.test
The code coverage can be generated by:
docker-compose run qleader-web coverage run -m pytest
Saving the coverage results can be done like this:
docker-compose run qleader-web coverage (e.g. "xml" / "json" / "html" ... more options with "--help")
Basically every functionality is or should be tested by unit tests. See that especially the tests that require data handling, the Django REST framework's testing models (e.g. APITransactionTestCase) require client actions such as methods POST and GET to access the databases made in the tests. Therefore, it is good to recognize that some of the functionalities / methods are tested using the client calls (handled in the views.py). For example, when testing the create_result method from the initializers.py, instead of calling the create_result straight, the views.py's result_list (responsible for actions when POST method to url ".../api/") is been called which then calls it.
Since the application involves several intertwined objects and analyzing benchmark results on a separate back-end, testing each "nook and cranny" makes it easier to ensure that inputs and outputs are valid, tasks get executed and so on.
The UI-functionality is not tested, but during the development Google Lighthouse reports have been generated and changes have been made accordingly. Challenges with f.ex. bad layout have been "tested" in this way.
Name of the test function must start with 'test'.