Daily Test Coverage ImproverResearch and Plan

[github-actions]

Current State of Test Coverage

Existing Test Infrastructure

The repository has a mixed JavaScript/TypeScript and Python codebase with testing infrastructure already in place:

JavaScript/TypeScript Testing:

• Framework: Vitest with @vitest/coverage-v8
• Test location: tests/ directory
• Current tests:
  • tests/ContactForm.test.tsx - Comprehensive React component tests covering accessibility, validation, submission, error handling (285 lines)
  • tests/unit/emailValidation.test.ts - Email validation unit tests
• Testing library: @testing-library/react for component testing with JSDOM
• Configuration: vitest.config.js exists with proper coverage setup

Python Testing:

• Framework: pytest with pytest-cov
• Test location: tests/ directory
• Current tests:
  • tests/test_contact_handler.py - Server-side handler tests with GDPR compliance scenarios (334 lines)
  • Tests cover validation, security, rate limiting, audit logging, and GDPR rights
• Configuration: pytest.ini configured

Coverage Infrastructure:

• Coverage steps action configured at .github/actions/daily-test-improver/coverage-steps/action.yml
• Generates combined reports in coverage/ directory
• Recent logs show tests have import/module issues preventing successful coverage collection

Code Structure Analysis

Frontend Code:

• main.js - Main application entry point with form handling
• src/components/ContactForm.tsx - React contact form component (184 lines) with accessibility features
• src/api/contact.ts - API client functions
• src/utils/validation.ts - Validation utilities (email, input sanitization)
• Basic HTML structure in index.html

Backend Code:

• server/contact_handler.py (363 lines) - Comprehensive GDPR-compliant contact handler with:
  • ContactFormData dataclass with validation
  • AuditLogger for compliance tracking
  • DataRetentionManager for GDPR retention policies
  • ContactFormHandler with rate limiting and CSRF protection
  • GDPR data export/deletion handlers (handle_data_export_request, handle_data_deletion_request)
  • Security utilities: IP hashing, user agent sanitization, CSRF validation
• backend/ directory structure (contents not yet fully explored)

Current Coverage Status

Recent coverage run findings:

• ✅ Test infrastructure is properly configured
• ❌ Python tests have import errors - trying to import from modules that don't match the actual implementation
• ⚠️ JavaScript/TypeScript tests reference API and utility modules that may not exist yet
• ℹ️ The contact handler implementation (ContactFormHandler) doesn't match what tests expect (ContactHandler)

Key insight: The tests were written before the actual implementation, leading to mismatches. This is actually an opportunity - we have comprehensive test specifications showing what should be tested!

Test Coverage Improvement Strategy

Phase 1: Foundation Fixes

Priority 1: Align Implementation with Tests

The existing test files provide excellent specifications but have import mismatches:

1. Python Backend (server/contact_handler.py):

   • Tests import ContactHandler but code has ContactFormHandler
   • Tests import functions like validate_contact_data, encrypt_sensitive_data, check_rate_limits which don't exist as standalone functions
   • Strategy: Either refactor implementation to match test expectations OR update tests to match current implementation
   • Recommendation: Keep implementation, fix tests - the current implementation is well-structured

2. Frontend Implementation Gaps:

   • Tests import from src/api/contact.ts (functions: submitContactForm, logAuditEvent)
   • Tests import from src/utils/validation.ts (functions: validateEmail, sanitizeInput)
   • ContactForm.tsx references these but they may not exist yet
   • Strategy: Create missing modules to support the component and tests

Phase 2: Systematic Coverage Expansion

High-Impact Areas (Priority Order):

1. Backend Python - server/contact_handler.py (Highest Priority)

• Coverage opportunity: ~80-90% of 363 lines
• Test focus:
  • All ContactFormData validation edge cases (length limits, format validation, dangerous content)
  • AuditLogger.log_event() with various event types and data structures
  • DataRetentionManager policy calculations and expiry dates
  • Utility functions: hash_ip_address, sanitize_user_agent, validate_csrf_token
  • ContactFormHandler.check_rate_limit() with time-based scenarios
  • ContactFormHandler.process_submission() - happy path, validation errors, rate limiting, CSRF failures
  • GDPR handlers: handle_data_export_request, handle_data_deletion_request

2. Frontend Utilities - src/utils/validation.ts and src/api/contact.ts

• Coverage opportunity: ~90% of utility code (currently may not exist)
• Test focus:
  • Email validation: valid formats, invalid formats, dangerous content, edge cases
  • Input sanitization: XSS prevention, script tag removal, length limits
  • API client: request construction, error handling, response parsing

3. Main Application - main.js

• Coverage opportunity: ~60-70% of entry point logic
• Test focus:
  • Form initialization
  • Event handling
  • Accessibility features setup
  • GDPR compliance initialization

4. Backend API - backend/ directory

• Coverage opportunity: TBD (requires exploration)
• Test focus: API endpoints, authentication, request validation

Phase 3: Advanced Testing Strategies

Security & Compliance Testing:

• XSS attack prevention (multiple payload types)
• SQL injection detection and blocking
• CSRF token validation
• Rate limiting under various scenarios
• GDPR compliance workflows (consent, export, deletion)

Edge Case & Boundary Testing:

• Empty/null/undefined inputs
• Maximum length inputs
• Special characters and Unicode
• Concurrent requests
• Time-based scenarios (retention, rate limits)

Integration Testing:

• Full form submission workflow (frontend → API → backend → audit log)
• Error propagation across layers
• GDPR request workflows end-to-end

Test Organization Strategy

Directory Structure:

tests/
├── unit/                    # Pure unit tests
│   ├── emailValidation.test.ts
│   ├── test_validation.py
│   └── test_audit_logger.py
├── integration/             # Integration tests
│   ├── test_api_endpoints.py
│   └── test_form_workflow.py
├── ContactForm.test.tsx     # Component tests
└── test_contact_handler.py  # Handler tests

Naming Conventions:

• JavaScript/TypeScript: *.test.{js,ts,tsx} or *.spec.{js,ts,tsx}
• Python: test_*.py following pytest conventions

Commands for Testing and Coverage

Build the project:

npm run build

JavaScript/TypeScript tests:

npm run test              # Run all JS/TS tests
npm run test:coverage     # Run with coverage report

Python tests:

pytest tests/                                           # Run all Python tests
pytest --cov=server --cov=backend tests/                # With coverage
pytest --cov=server --cov=backend --cov-report=html tests/  # HTML report

Generate combined coverage (automated):
The action at .github/actions/daily-test-improver/coverage-steps/action.yml handles:

• Installing dependencies (Node.js and Python)
• Running both test suites with coverage
• Generating combined coverage reports
• Uploading artifacts

Expected Coverage Targets

Overall Targets:

• Production code: 70-80% line coverage
• Critical paths (security, compliance): 90%+ coverage
• Utility functions: 85%+ coverage
• UI components: 70%+ coverage

Quality Metrics:

• All tests must be meaningful and test actual behavior
• Avoid coverage-chasing tests that don't validate correctness
• Focus on edge cases and error paths, not just happy paths
• Each test should have clear intent and documentation

Opportunities for High-Impact Improvements

1. Security Testing (Critical Priority)

The server/contact_handler.py contains security features that need comprehensive testing:

• CSRF token validation with invalid/expired/missing tokens
• Rate limiting edge cases (boundary conditions, concurrent requests)
• Input sanitization for XSS, SQL injection, command injection
• IP address hashing for privacy compliance

2. GDPR Compliance Testing (Critical Priority)

Required for enterprise deployments:

• Data retention policy enforcement
• Audit log completeness and format
• Right to erasure implementation
• Right to data portability (export)
• Consent tracking and validation

3. Error Path Coverage

Current tests focus on success cases:

• Network failures and retries
• Validation error propagation
• Database connection errors
• Timeout handling
• Unexpected exceptions

4. Integration Points

Test the boundaries between components:

• Frontend → Backend API contract
• Validation → Audit logging pipeline
• Rate limiter → Request handler flow
• Error handling across all layers

5. Missing Module Implementation

Create missing modules referenced by tests:

• src/api/contact.ts - API client functions
• src/utils/validation.ts - Validation utilities
• Ensure they match test expectations

Challenges and Considerations

Technical Challenges:

1. Import path mismatches - Tests expect different module structure than implementation
2. Mock complexity - Testing GDPR workflows requires mocking storage, time, and external services
3. Async testing - Form submissions and API calls need proper async test patterns
4. Rate limiting tests - Time-based features need careful mocking

Strategic Considerations:

1. Refactor vs. Adapt - Should we change implementation to match tests or vice versa?
2. Test maintenance - Keep tests simple and maintainable while thorough
3. CI/CD integration - Ensure tests run efficiently in CI pipeline
4. Coverage vs. Quality - Focus on meaningful tests, not just hitting coverage numbers

Questions for Maintainers

1. Module structure: Should we refactor ContactFormHandler to ContactHandler to match existing tests, or update tests?

2. Missing modules: Should we create src/api/contact.ts and src/utils/validation.ts to match test imports?

3. Coverage targets: Are there specific coverage percentage requirements for CI/CD?

4. Test organization: Is the current test directory structure acceptable, or should we reorganize?

5. GDPR testing: Do you have test/staging infrastructure for testing data export/deletion workflows?

6. Dependencies: Any restrictions on adding test utilities or mocking libraries?

---

How to Control this Workflow

You can manage this workflow using these commands:

Disable the workflow:

gh aw disable daily-test-improver --repo microsoftgbb/corporate-website

Enable the workflow:

gh aw enable daily-test-improver --repo microsoftgbb/corporate-website

Run the workflow manually with repeats:

gh aw run daily-test-improver --repo microsoftgbb/corporate-website --repeat <number-of-repeats>

View workflow logs:

gh aw logs daily-test-improver --repo microsoftgbb/corporate-website

What Happens Next

Phase 2 (Next run): The workflow will analyze the codebase in detail to create or update the coverage steps configuration:

• Review and validate .github/actions/daily-test-improver/coverage-steps/action.yml
• Test the configuration by running it
• Create a pull request if updates are needed
• Document initial coverage baseline

Phase 3 (Subsequent runs): Once configuration is confirmed working, the workflow will systematically improve test coverage:

• Select specific low-coverage areas based on this plan
• Write comprehensive, meaningful tests
• Verify coverage improvements
• Create draft pull requests with measurable results

Repeat mode: If running with --repeat, the workflow automatically proceeds to the next phase

Human involvement: You can comment on this discussion anytime to provide feedback, adjust priorities, answer questions, or provide guidance. The workflow reads these comments in each subsequent run.

---

Note: This was intended to be a discussion, but discussions could not be created due to permissions issues. This issue was created as a fallback.

AI generated by Daily Test Coverage Improver

To add this workflow in your repository, run gh aw add githubnext/agentics/workflows/daily-test-improver.md@e43596e069e74a65cd7d93315091672d278c2642. See usage guide.

• expires on Mar 6, 2026, 9:25 AM UTC