Testing

Backend testing

Django Testing

To run all backend Unit and Integration tests, you can use:

docker exec -it pigeonhole-backend python manage.py test backend/

Django coverage

To get an overview of the code's coverage, use:

docker exec -it pigeonhole-backend coverage run manage.py test backend/

docker exec -it pigeonhole-backend coverage report

Fill database with testdata

To quickly fill the database with dummy data to test the application:

docker exec -it pigeonhole-backend python manage.py loaddata backend/fixtures.json

Model testing guidelines

TODO

API testing guidelines

4 Django TestCase classes for every view, each in a seperate file:

• Admin Teacher
• Teacher
• Student
• Unauthorised

A Testcase is a closed test that creates a mock database in RAM. Tests are executed sequentially, so note that tests in one TestCase influence each other.

For every class we test:

• Every route with valid id's
• Every route with invalid id's (when multiple id's verify for all)
• Relations between fields (example: are dates correct?)

We use different response status codes in the API, as is illustrated for every authentication level below:

• Admin Teacher: the admin is allowed to perform every valid action, every invalid action should throw a HTTP_404_NOT_FOUND
• Teacher: the teacher is allowed to acces all his objects and create all objects, when accessing actions of another teacher the response should return HTTP_403_FORBIDDEN
• Student: a student is only allowed to manage his own submissions and view the objects to which it has acces, otherwise return HTTP_403_FORBIDDEN
• Unauthorised: every response should return HTTP_403_FORBIDDEN

Successful action response codes: status.HTTP_200_OK, HTTP_201_CREATED, HTTP_204_NO_CONTENT