Web app tests

[A-lexisL]

Web API Testing Instructions

Overview

We use pytest + normal python class instead of APITestCase for testing our web APIs. The testing approach focuses on ensuring each endpoint works correctly for both authenticated and non-authenticated users.

pytest doc:
https://pytest-django.readthedocs.io/en/latest/tutorial.html
https://docs.pytest.org/

Setup

1. please add newest version of pytest pytest-django, and factory-boy to pyproject.toml dev dependency-group and use uv sync --all-groups to sync the dependencies. Search on pypi.org to get the dependency information.
   e.g.

[dependency-groups]
dev = [
    ...
    "pytest==xxx",
    ...
]

Add config in pyproject.toml

[tool.pytest.ini_options]
django_settings_module = "website.settings"
python_files = ["tests.py", "test_*.py", "*_tests.py"]
addopts = "--reuse-db --strict-markers"
testpaths = ["apps"]

Fixtures

doc: https://docs.pytest.org/en/stable/reference/fixtures.html#fixtures
Fixtures are reusable data that will be automatically imported by pytest. Fixtures could depend on other fixtures as well. With fixtures, no need for setup(). Define fixtures in apps/web/tests/conftest.py.

Test Clients

• auth_client: An authenticated client for testing protected endpoints. Reuse this fixture for authenticated test.
• base_client: An anonymous client for testing public endpoints. Reuse this fixture for nonauthenticated test.

Factories

Wrap up factories(Course, Review, Vote, etc) in fixtures for sharing the same usable data among different tests.

Test Organization

Organize tests into different test files by functionality and usage patterns:
e.g.

tests/
    - test-auth.py
    - test-course.py
    - ...

1. Authentication Tests

• Test user status endpoint
• Verify authentication requirements
• Check access control for protected endpoints

2. Course Management Tests

• Course listing and filtering
• Course details retrieval
• Department listings

3. Review Management Tests

• Review creation and validation
• Review retrieval and filtering
• Review updates and deletions
• User review permissions

4. Voting System Tests

• Course voting (quality/difficulty)
• Review voting (kudos/dislike)
• Vote validation and updates

Testing Approach

test should be comprehensive, covering most scenarios of requests.

1. success + errors(documented in docstrings of each endpoint)
2. request with params(e.g. q, author params for CourseReviewAPI)
3. Most endpoints behave differently based on authentication status:

• Test with authenticated client(auth_client fixture) - full functionality
• Test with anonymous client(base_client fixture) - limited access
• Verify permission restrictions are enforced

Example Test Structure

class TestCoursesAPI:
    def test_list_courses_anonymous(self, base_client):
        # Test public access to course listing

    def test_list_courses_authenticated(self, auth_client):
        # Test enhanced features for authenticated users

    def test_filter_courses_by_department(self, auth_client):
        # Test filtering functionality

    def test_invalid_filter_parameter(self, auth_client):
        # Test error handling

Key Areas to Test

1. API Validation

• Required field validation(missing field errors)
• Data type validation
• Range validation for scores and ratings

2. Permission Systems

• Review creation restrictions
• Vote ownership rules
• Resource access controls

3. Data Integrity

• Vote counting accuracy
• Score calculation correctness
• Relationship consistency

4. Performance Considerations

• Pagination behavior
• Query optimization verification
• Large dataset handling