Skip to content

Test Cases for patient,doctor and medical camp routes.

Satyapranavanadh Rayapureddy requested to merge routes_dfm_tests into develop

Overview

This Merge Request adds unit tests for multiple API route modules to ensure correctness, reliability, and maintainability of backend endpoints.

What does this MR do and why?

This MR introduces unit tests for the following API routes:

  • tests/test_api/test_doctor_routes.py
  • tests/test_api/test_family_routes.py
  • tests/test_api/test_medical_camp_routes.py

The purpose is to:

  • Validate API endpoint behavior
  • Catch regressions early
  • Improve code coverage
  • Ensure backend stability before deployment

Changes Made

  • Added unit tests for doctor-related routes
  • Added unit tests for family-related routes
  • Added unit tests for medical camp routes
  • Used pytest framework for testing
  • Verified endpoints with different scenarios (success, failure, edge cases)

Technical Details

Testing framework: pytest

Coverage includes:

  • API response validation
  • Status code checks
  • Input validation scenarios
  • Ensured compatibility with existing FastAPI backend structure

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to change)
  • 📝 Documentation update
  • ♻️ Refactor (no functional changes)
  • ⚡ Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix
  • 🗑️ Deprecation (removing deprecated code)

Related Issues / References

Link to related issues using GitLab syntax:

How to Validate Locally

Previous Behaviour:

  • Not 100% coverage for unit tests were present for doctor, patient (family), and medical camp routes
  • API endpoints were not systematically validated
  • Bugs or regressions could go unnoticed

Changes Made:

Added unit tests for:

  • test_doctor_routes.py
  • test_family_routes.py
  • test_medical_camp_routes.py
  • Implemented test cases covering success, failure, and edge scenarios
  • Used pytest for executing tests

Testing Done

[ ] Unit tests added/updated [ ] API endpoint tests passing

Test Cases Covered:

Scenario Expected Result Status
doctor routes Coverage - 70% 100% ✅
family routes coverage - 26% 100% ✅
medical cam routes coverage - 72% 100% ✅

Test Commands Run:

Example: Run all tests

pytest

Example: Run specific test file

pytest tests/test_api_v1/test_patient_routes.py -v

Example: Run with coverage

pytest --cov=app


## Code Quality Checklist

### Code Standards

[x] Code follows project conventions (naming, structure, formatting)
[x] No debug statements or commented-out code left (unless necessary and intended)
[x] No unused imports, variables, or functions
[x] No duplicate code (DRY principle followed)
[x] Type hints are properly defined (no `Any` unless justified and no mypy type check errors)
[x] Ruff checks pass:
  ```bash
  ruff check .
  ruff format . --check

Python & FastAPI Best Practices

  • Functions follow single-responsibility principle
  • Async/await used correctly (no blocking calls in async functions)
  • Dependency injection used appropriately
  • Pydantic models used for request/response validation
  • SQLAlchemy queries are optimized (no N+1 queries)
  • Error handling is comprehensive (try/except with proper logging)

API Design

  • RESTful conventions followed
  • Proper HTTP status codes returned
  • Input validation implemented
  • Authentication/authorization enforced
  • Role Base access control used for user restriction
  • API documentation (docstrings) updated

Database & Migrations

  • Database migrations created (if schema changed)
  • Database migrations version is pointing to the latest version (and version name follows project conventions)
  • Migrations are reversible (migrations contain downgrade scripts)
  • Indexes added for frequently queried fields
  • No raw SQL queries (using SQLAlchemy ORM)
  • Data integrity constraints maintained

Security

  • No sensitive data logged (passwords, tokens, PII)
  • SQL injection prevention verified (ORM used)
  • Input sanitization implemented
  • Authentication tokens handled securely
  • CORS settings appropriate
  • Security scan passes: 
    bandit -r app/

Error Handling

  • Errors are caught and handled gracefully
  • User-friendly error messages returned
  • Errors are logged appropriately
  • HTTP error responses follow API standards

Documentation

  • README.md updated (if setup steps changed)
  • .env.example updated (if new env vars added)
  • API documentation updated (docstrings, OpenAPI specs)
  • CHANGELOG.md will be updated (if applicable)
  • Code comments explain complex logic (not what, but why)

MR Acceptance Checklist

Quality & Correctness

  • Code works as intended and solves the stated problem
  • No bugs introduced (existing functionality not broken)
  • Edge cases handled appropriately

Maintainability

  • Code is readable and well-organized
  • Code is testable and well-tested
  • Follows project patterns and conventions

Acceptance Review

  • Reviewed by at least 1 teammate
  • Reviewed by product owner
Edited by Satyapranavanadh Rayapureddy

Merge request reports