Gator Check-In.

Making application behavior easier to verify

Gator Check-In is a team-built wellness application with authentication, daily check-ins, journaling, calendar entries and statistics. My main contribution was backend testing and integration: I added pytest infrastructure, endpoint-focused tests, test configuration and supporting documentation. The application features were shared team work, with other teammates responsible for the main frontend and backend implementations. My testing and integration PR.

Testing through the application boundary

The backend uses a Flask application factory with SQLAlchemy, migrations and JWT support. Route groups connect incoming requests to validation, authentication and persisted models. The factory accepts configuration overrides, which creates a practical entry point for constructing a test application. Application factory.

I used fixtures to isolate an in-memory SQLite database and supply authenticated test requests. That lets a test exercise a request and inspect its result without depending on a developer's existing database contents. It also makes setup reusable across endpoint groups. Test fixtures.

The test source contains 37 functions across five modules covering authentication, calendar, check-ins, journal and statistics. The checks include successful requests, invalid input, duplicates, absent records, persistence, date filtering, ordering and numerical averages. The count describes the source at revision 64e4419; it is not a coverage percentage or a claim about the latest execution result. Test modules.

Checking behavior beyond a successful response

A useful endpoint test asks more than whether a request returned successfully. For example, a check-in path also needs to handle invalid values and duplicate submissions, while a statistics path needs to calculate the expected result from persisted records. Those cases connect the HTTP contract to the application's data behavior. Check-in and statistics tests.

The database model also defines the limits of what a request test proves. At this revision, CheckIn has no database-level unique constraint on user and date. A sequential duplicate-request check therefore does not establish protection against concurrent duplicate creation. Authorization boundaries and user isolation likewise need their own targeted cases. Persistence models.

Collaboration and remaining work

I delivered this work through a pull request that received a teammate's approval. The patch brings the test setup, application configuration changes and documentation together, making the integration visible as a reviewable change. PR #59, approval record.

The team presentation provides a recorded walkthrough. The next useful improvements would be a maintained CI execution record and explicit checks for cross-user access and concurrent writes. The contribution already provides a repeatable testing structure and concrete examples of the application's expected behavior; those additional checks would make its regression status and boundaries easier to assess.