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

When an action is both invalid and forbidden, the forbidden response code should be returned or else non authorised user could get knowledge of the information in the database. Successful action response codes: status.HTTP_200_OK, HTTP_201_CREATED, HTTP_204_NO_CONTENT