Testing Strategy

Relevant source files

The following files were used as context for generating this wiki page:

• finder/tests.py
• CONTRIBUTING.md
• TODO.md
• README.md
• generate_sample_data.py
• roomfinder/settings.py

The testing strategy for the Campuspal Room Finder project currently relies on a combination of manual verification, robust sample data generation for feature testing, and static code analysis (linting). While a formal automated testing suite is planned for the future, the current approach ensures that new contributions are functional and do not break existing features before being merged.

The strategy is centered around a developer-led verification process that includes setting up a realistic database, running the server locally, and manually checking key functionalities like data uploads and room searching. This is complemented by code quality checks using tools like Flake8 to maintain code standards.

Current State of Automated Testing

The project is set up to support Django's built-in testing framework, but automated tests have not yet been implemented. The primary file for tests within the finder application is currently a placeholder.

Sources: finder/tests.py, TODO.md

finder/tests.py

This file is intended to house the application's tests. At present, it is empty and contains a TODO comment indicating that tests need to be added.

# Create your tests here.
# TODO: Add proper tests for the finder application

Sources: finder/tests.py:1-2

The TODO.md file acknowledges this and lists "add tests to tests.py" as a future task to resolve an F401: Unused import linting error.

Sources: TODO.md:12-13

Manual Testing and Verification

The CONTRIBUTING.md file outlines a clear, mandatory process for manual testing that all contributors must follow before submitting a pull request. This process ensures that core application features are working as expected.

Sources: CONTRIBUTING.md:19-24

Manual Testing Workflow

The following diagram illustrates the steps a developer should take to test their changes locally.

This diagram shows the manual testing flow from making code changes to creating a pull request.
Sources: CONTRIBUTING.md:15-24

Steps for Local Testing

Step	Command	Description
1. Run Tests	python manage.py test	Executes the (currently empty) test suite. This command is included as a placeholder for future automated tests.
2. Run Server	python manage.py runserver	Starts the local development server to enable manual verification.
3. Verify Uploads	Navigate to /upload/	Manually test the Excel file upload functionality for rooms and timetables.
4. Verify Search	Navigate to /	Manually test the core room search and timeline display functionality.

Sources: CONTRIBUTING.md:19-24

Data Generation for Testing

A significant part of the testing strategy involves using a realistic, large-scale dataset. The generate_sample_data.py script was created for this purpose. It generates rooms.xlsx and timetable.xlsx files with a substantial amount of randomized but structured data. This allows for thorough testing of the application's performance, timeline generation logic, and search categorization under conditions that mimic a real-world campus environment.

*Sources: README.md:65-70, generate_sample_data.py

Data Generation and Loading Process

The README.md file details the commands required to prepare the database for testing.

This diagram shows the sequence of commands to generate and load sample data into the database.
*Sources: README.md:180-188, generate_sample_data.py:73-74

Key commands for data setup:

1. Generate Data: python generate_sample_data.py
2. Clear Database: python manage.py shell -c "from finder.models import Room, ClassSchedule; Room.objects.all().delete(); ClassSchedule.objects.all().delete()"
3. Load Data:
   • python manage.py load_rooms_excel
   • python manage.py load_timetable

Sources: README.md:184-188

Code Quality and Linting

Static code analysis using Flake8 is an implicit part of the testing strategy, aimed at maintaining code quality and preventing common errors. The TODO.md file documents a list of existing linting issues that are slated to be fixed in the future.

Sources: TODO.md:3-6, CONTRIBUTING.md:30

Identified Linting Issues

The following issues have been identified and are tracked for future resolution:

Error Code	Description	Affected Files
E501	Line too long (>120 characters)	finder/management/commands/load_timetable.py, finder/views.py
F401	Unused import	finder/tests.py
E261	At least two spaces before inline comment	roomfinder/settings.py
W291	Trailing whitespace	roomfinder/settings.py
E303	Too many blank lines	roomfinder/settings.py
W504	Line break after binary operator	finder/views.py

Sources: TODO.md:8-33

The plan is to fix these issues and then update the CI pipeline to remove the --ignore flag, enforcing stricter code quality checks automatically.

Sources: TODO.md:41-42

Future Enhancements

The project documentation indicates a clear path toward a more robust testing strategy. The TODO.md file mentions a plan to configure a PostgreSQL database in the CI environment for more realistic tests, moving away from the SQLite fallback. This, combined with the plan to populate finder/tests.py with actual tests, shows an intent to build a comprehensive automated testing suite.

Sources: TODO.md:36-38, CONTRIBUTING.md:16