Week 4 #

Testing and QA #

Test Coverage #

Implemented comprehensive test suites covering:

• test_bookings: Booking lifecycle (create/read/update/delete)
• test_books: CRUD operations with library associations
• test_libraries: Location management and city listings
• test_managers: Role-based access control
• test_search: Filtering by title/author/genre
• test_users: Registration, authentication, and profile management

Test Types #

✅ Integration Tests

• API endpoint validation with status code checks
• Database interaction testing via AsyncClient
• Cross-entity dependencies (e.g., bookings require users/books)

✅ Functional Tests

• CRUD workflows for all core entities
• State transitions (e.g., booking status changes)
• Edge cases (404 handling, duplicate prevention)

Evidence of test execution #

Code coverage report #

Total coverage: 52% (13/25 test suites)

CI/CD #

CI (Continuous Integration)

For CI, we maintain a dedicated test database, which was migrated from the main production database. This environment is used to verify endpoint functionality. Our backend developer wrote automated tests using pytest. These tests perform actions such as creating or deleting objects and then assert that the returned status codes match the expected values. Sensitive keys required for testing are securely stored in GitHub Secrets.

CD (Continuous Deployment)

Continuous deployment is triggered automatically whenever changes are pushed to the main branch. A GitHub Actions job connects to the remote server via SSH, using a private key stored in GitHub Secrets. On the server, the workflow navigates to the project directory, performs a git pull, stops any running containers, and then rebuilds and restarts the application using docker-compose up -d –build.

Links to CI/CD configuration files #

CI/CD configuration file (deploy.yml)

Deployment #

Staging Environment #

Process:

• Automated CI/CD pipeline via GitHub Actions
• Trigger: Push to main branch
• Workflow: deploy.yml

Key Steps:

1. GitHub runner executes build/test stages
2. SSH connection to server using deploy keys
3. Container orchestration:
   • Pulls latest Docker images
   • Graceful container restart

Tech Stack:

• GitHub Actions (CI/CD)
• Docker containers
• SSH key authentication

Vibe Check #

Progress #

This week, the team completed key frontend features including the admin login system, dashboard with library management, library editing, dynamic manager loading, and search/filter functionality. Adaptive styling was implemented with responsive breakpoints, and the admin panel interface was refined. The domain name was purchased and configured. On the backend, testing tasks were completed, and a new endpoint was created to display books without duplicates. Additionally, CI was configured, and a logging and monitoring system was set up.

Frontend #

✅ Adaptive styling & breakpoints
✅ Admin panel: login, dashboard, library editor
✅ Search/filter UI

Backend #

✅ Search/filter API
✅ Book deduplication endpoint

DevOps #

✅ Domain configuration
✅ Logging/monitoring setup
✅ CI pipeline

Documentation #

✅ Report completion
✅ README updates

Roadblocks #

Skill Gap Adaptation

• Team members are encountering role-first challenges due to limited prior experience in:
  • Specific tech stack implementations
  • Domain-specific problem solving
• Current mitigation:
  • Peer knowledge sharing sessions

Novelty Factor

• High frequency of first-time scenarios requiring:
  • Extended research phases
  • Iterative solution validation

Team Dynamics #

Current State:

• High workload, but maintaining delivery pace.
• Shared fatigue with positive attitude.

Support Needed:

• Prioritization review to balance tasks.

Weekly commitments #

Individual contribution of each participant #

Plan for Next Week #

Frontend Development #

• Feature Completion
  • Book addition form
  • Library management UI
  • Manager assignment flows

Backend Development #

• Performance & Testing
  • Load testing script implementation
  • Ollama integration research
• Maintenance
  • Bug fixes (if identified)

Confirmation of the code’s operability #

We confirm that the code in the main branch:

• In working condition.
• Run via docker-compose (or another alternative described in the README.md).