Skip to content

test: improve API route coverage

Sahasra Reddy requested to merge test-coverage into develop

🚀 Merge Request

Overview

Improved unit test coverage for medicine, patient, and user route modules to ensure reliable API behavior across all scenarios.


What does this MR do and why?

  • Increased test coverage for critical API routes
  • Added missing test cases for edge cases and error handling
  • Covered all logical branches (success, failure, exceptions)
  • Improves backend stability and reduces regression risks

Changes Made

  • Updated:
    • tests/test_api/test_medicine_routes.py
    • tests/test_api/test_patient_routes.py
    • tests/test_api/test_users_routes.py
  • Added:
    • Success case tests
    • 404 / not found scenarios
    • 400 / validation errors
    • 403 / unauthorized checks
    • Exception handling tests
  • Mocked all service layer dependencies

Type of Change

  • 🐛 Bug fix
  • New feature
  • 💥 Breaking change
  • 📝 Documentation update
  • ️ Refactor
  • Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix
  • 🗑️ Deprecation

Related Issues / References

Closes #66 (closed)


Screenshots

Screenshot_from_2026-03-20_14-54-11

How to Validate Locally

pytest
uv run pytest --cov=app tests/ 

Code Quality Checklist

Code Standards

  • Code follows project conventions (naming, structure, formatting)
  • No debug statements or commented-out code left (unless necessary and intended)
  • No unused imports, variables, or functions
  • No duplicate code (DRY principle followed)
  • Type hints are properly defined (no Any unless justified and no mypy type check errors)
  • Ruff checks pass:
    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)

Known Limitations / Technical Debt

Additional Notes


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 Sahasra Reddy

Merge request reports

Loading