Testing

Testing the WebMark2

Tests are conducted with Pytest, Pytest-Django and Django REST framework

Unit tests

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")  

What is tested

Basically every functionality is or should be tested by unit tests.

When testing those methods that are implemented with Django REST framework, instead of calling the methods straight from the unit tests, the methods are tested using requests. For example, to see how some method let's say home in views/home.py works and how it responses, the correct way is to make a request to the path ("") which home method is responsible for. The method requires a request to work. More about DRF's testing.

Reasons for testing

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.

What is not tested

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.

Writing tests

Name of the test function must start with 'test'.