Skip to content

Daily Test Coverage ImproverResearch and Plan #14

@github-actions

Description

@github-actions

Current State of Test Coverage

I've analyzed this repository's testing infrastructure and identified opportunities for systematic test coverage improvement.

Existing Test Infrastructure

Testing Frameworks:

  • JavaScript/TypeScript: Vitest 4.0.18 with @vitest/coverage-v8 provider
  • Python: pytest 9.0.2 with pytest-cov 7.0.0
  • Component Testing: @testing-library/react 16.3.2
  • Accessibility Tools: axe-core, pa11y, lighthouse-cli (available but not tested yet)

Test Organization:

tests/
├── ContactForm.test.tsx          # React component tests (285 lines)
├── test_contact_handler.py       # Backend handler tests (333 lines)
├── unit/
│   ├── emailValidation.test.ts   # TDD email validation (426 lines)
│   └── test_validation.py        # Python validation tests (15 lines)
└── integration/
    └── test_api_endpoints.py     # API integration tests (19 lines)

Total Test Code: ~1,078 lines across 5 test files

Source Code Inventory

JavaScript/TypeScript (673 lines):

  • src/api/contact.ts (260 lines) - GDPR-compliant form submission, audit logging, data export/deletion
  • src/utils/validation.ts (216 lines) - Email/phone/URL validation, XSS prevention, rate limiting, data retention
  • src/components/ContactForm.tsx (183 lines) - React form with WCAG 2.1 AA accessibility
  • frontend/components/Header.tsx (14 lines) - Simple header component
  • main.js (~100 lines estimated) - Main application entry point

Python (378 lines):

  • server/contact_handler.py (362 lines) - Server-side GDPR compliance, rate limiting, audit logging, data retention
  • backend/api/users.py (16 lines) - FastAPI user endpoints

Total Source Code: ~1,151 lines

Current Coverage Status

The repository has a coverage steps configuration at .github/actions/daily-test-improver/coverage-steps/action.yml that generates combined coverage reports. However, examining the most recent coverage-steps.log shows:

Issues Identified:

  1. ❌ JavaScript tests: Some tests may be failing or incomplete
  2. ❌ Python tests: Import errors in test files (trying to import non-existent classes)
  3. ⚠️ Coverage measurement incomplete due to test failures

From existing test files, I can estimate:

  • React components: ~70% coverage (ContactForm is well-tested)
  • API utilities: ~30% coverage (many functions untested)
  • Validation utilities: ~40% coverage (email validation has comprehensive TDD tests but implementation missing)
  • Backend Python: ~20% coverage (extensive test file but import errors prevent execution)
  • Frontend JavaScript (main.js): ~0% coverage (no tests found)

Test Coverage Improvement Plan

Strategy Overview

This plan focuses on high-value, security-critical code and GDPR compliance functions that currently have low or zero test coverage. I'll work systematically from highest priority (security/compliance) to lower priority (UI components).

Phase 2: Coverage Steps Configuration

Status: ✅ Already exists at .github/actions/daily-test-improver/coverage-steps/action.yml

The configuration successfully:

  1. Sets up Node.js 18 and Python 3.11 environments
  2. Installs testing dependencies (Vitest, pytest, coverage tools)
  3. Creates Vitest configuration for JavaScript coverage
  4. Runs JavaScript/TypeScript tests with coverage
  5. Runs Python tests with coverage
  6. Generates combined coverage reports
  7. Uploads coverage artifacts

Commands to build and test:

# Build project
npm run build

# Run JavaScript/TypeScript tests with coverage
npm run test:coverage

# Run Python tests with coverage
pytest --cov=server --cov=backend --cov-report=html:coverage/python --cov-report=json

# Run combined coverage (automated in CI)
# See .github/actions/daily-test-improver/coverage-steps/action.yml

Phase 3: Systematic Test Coverage Improvement

Priority 1: Security & GDPR Compliance (Highest Business Risk)

Target: src/api/contact.ts (260 lines, ~30% covered)

Critical untested functions:

  • submitContactForm() - Form submission with CSRF protection
  • logAuditEvent() - Compliance audit logging (critical for GDPR)
  • exportUserData() - GDPR Right to Data Portability
  • deleteUserData() - GDPR Right to Erasure
  • Helper functions: getCSRFToken(), getHashedIP(), generateUUID(), getAuthToken()

Testing approach:

  • Mock fetch API for network calls
  • Test CSRF token validation
  • Verify audit logging for all critical operations
  • Test error handling and security edge cases
  • Verify GDPR compliance requirements

Expected impact: +50% coverage on critical compliance code

Priority 2: Input Validation & Security (XSS/Injection Prevention)

Target: src/utils/validation.ts (216 lines, ~40% covered)

Critical untested functions:

  • sanitizeInput() - XSS prevention (currently has NO tests despite security criticality!)
  • validatePhoneNumber() - Phone format validation
  • validateURL() - URL validation with protocol restrictions
  • hashSensitiveData() - Privacy compliance hashing
  • RateLimiter class - Abuse prevention (needs comprehensive testing)
  • DataRetentionManager class - GDPR retention policies

Notable opportunity: tests/unit/emailValidation.test.ts has 426 lines of comprehensive TDD tests but the implementation appears incomplete. This should be addressed.

Testing approach:

  • Comprehensive edge case testing (empty, null, undefined, malicious inputs)
  • Security testing (XSS payloads, SQL injection attempts, command injection)
  • Boundary testing (max lengths, special characters)
  • Rate limiter time-based testing with mocked timers

Expected impact: +60% coverage on security-critical validation code

Priority 3: Backend Processing & Rate Limiting

Target: server/contact_handler.py (362 lines, ~20% covered)

The test file tests/test_contact_handler.py exists but has import errors. Need to:

  1. Fix import errors in existing test file
  2. Expand tests for:
    • ContactFormHandler.process_submission() - End-to-end submission flow
    • ContactFormHandler.check_rate_limit() - Rate limiting logic
    • DataRetentionManager - Retention policy calculations
    • Security functions: hash_ip_address(), validate_csrf_token()
    • GDPR handlers: handle_data_export_request(), handle_data_deletion_request()

Testing approach:

  • Fix import paths and module structure
  • Mock time-dependent functions for rate limiting tests
  • Test all validation edge cases
  • Verify audit logging occurs for all operations
  • Test GDPR data export/deletion workflows

Expected impact: +70% coverage on backend code

Priority 4: Main Application Entry Point

Target: main.js (~100 lines, 0% covered)

Currently has NO test coverage. Need to create:

  • Tests for form initialization
  • Tests for event handlers
  • Tests for GDPR compliance initialization
  • Tests for accessibility features initialization

Testing approach:

  • DOM-based testing with JSDOM
  • Event simulation and verification
  • Mock external dependencies

Expected impact: +60-70% coverage on main.js

Priority 5: API Endpoints

Target: backend/api/users.py (16 lines, unknown coverage)

Expand tests/integration/test_api_endpoints.py (currently only 19 lines) to cover:

  • get_users() - List users endpoint
  • create_user() - User creation with validation
  • Error cases (missing required fields, invalid data)
  • HTTP status codes and error responses

Testing approach:

  • Use FastAPI's TestClient
  • Test happy paths and error cases
  • Verify validation rules
  • Test response formats

Expected impact: +80-90% coverage on API endpoints

Priority 6: React Components

Target: frontend/components/Header.tsx (14 lines, unknown coverage)

Small component but should have basic tests:

  • Rendering test
  • Navigation elements present
  • Accessibility attributes

Testing approach:

  • React Testing Library
  • Simple snapshot or structure tests

Expected impact: +80% coverage on Header component

Testing Best Practices

Test Organization:

  • Unit tests in tests/unit/ matching source file structure
  • Integration tests in tests/integration/
  • Component tests in tests/ root
  • Name pattern: test_(function)_(scenario)_(expected)

Test Quality Standards:

  • Follow AAA pattern (Arrange, Act, Assert)
  • Include docstrings explaining compliance/security requirements
  • Test both happy paths AND error paths
  • Use descriptive assertions with helpful error messages
  • Mock external dependencies (network, file system, time)

Coverage Targets:

  • Overall: 70-80%
  • Security/GDPR code: 90%+ (highest priority)
  • Validation functions: 85%+
  • API endpoints: 80%+
  • UI components: 70%+

Opportunities for Major Coverage Gains

1. Fix Existing Broken Tests (Quick Win)

Impact: Immediate baseline coverage measurement

The tests/test_contact_handler.py file has 333 lines of tests but import errors prevent execution. Fixing these imports will immediately enable coverage measurement for backend code.

2. Implement TDD Email Validation (Quick Win)

Impact: +426 lines of implementation with 100% coverage

tests/unit/emailValidation.test.ts has comprehensive TDD tests (426 lines) but the implementation may be incomplete. This is a perfect TDD scenario - tests exist, just need to ensure implementation passes them.

3. Add Security Function Tests (High Value)

Impact: Prevents security vulnerabilities

Critical security functions like sanitizeInput(), validateCSRFToken(), and hashSensitiveData() currently have minimal or no test coverage despite being essential for preventing XSS, CSRF, and other attacks.

4. GDPR Compliance Testing (Regulatory Requirement)

Impact: Ensures regulatory compliance

Functions like logAuditEvent(), exportUserData(), deleteUserData(), and data retention managers are legally required to work correctly. Comprehensive testing of these functions is not just good practice but potentially a regulatory requirement.

5. Create main.js Tests (0% to ~70%)

Impact: Significant coverage increase

The main application entry point has zero tests. Creating a comprehensive test suite will dramatically improve overall repository coverage.

Questions & Clarifications Needed

  1. TDD Email Validation: Should I implement src/utils/emailValidation.ts based on the existing 426-line test suite, or are those tests intended for a different purpose?

  2. Import Structure: The Python tests have import errors. Should I:

    • Fix the test imports to match current code structure?
    • Refactor the server code to match what tests expect?
    • Create missing classes/functions that tests are trying to import?
  3. Coverage Targets: What specific coverage percentages are you targeting?

    • Overall repository coverage?
    • Per-file or per-module coverage?
    • Any files that must have 100% coverage?
  4. Performance Testing: Should I add performance/load testing for:

    • Rate limiting effectiveness?
    • Form submission under load?
    • API endpoint response times?
  5. Security Testing: Should I add explicit security test suites for:

    • XSS prevention verification?
    • SQL injection prevention?
    • CSRF protection validation?
  6. Integration Testing: Should I expand integration tests to cover:

    • Full form submission workflows (frontend → API → backend)?
    • GDPR data export/deletion end-to-end flows?
    • Error propagation across layers?

How to Control this Workflow

Add comments to this discussion to provide feedback or adjustments to this plan.

Workflow Commands:

# Disable this workflow
gh aw disable daily-test-improver --repo microsoftgbb/corporate-website

# Enable this workflow  
gh aw enable daily-test-improver --repo microsoftgbb/corporate-website

# Run manually with multiple iterations
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

  1. Next Run - Phase 3: Since coverage steps configuration already exists, the next workflow run will:

    • Select a high-priority area from this plan (likely security/GDPR functions)
    • Create comprehensive tests for that area
    • Run tests to verify they work
    • Measure coverage improvement
    • Create a draft pull request with the test additions
    • Report coverage improvements in this discussion
  2. Subsequent Runs: Each run will:

    • Review this plan and any maintainer feedback
    • Select the next highest-priority uncovered area
    • Implement meaningful tests
    • Create draft PRs with measurable coverage improvements
    • Update this discussion with progress
  3. Repeat Mode: If running with --repeat, the workflow will automatically continue to Phase 3 and make iterative improvements without waiting for human review.

  4. Human Review: You can review this plan and provide feedback at any time. Add comments to:

    • Adjust priorities (e.g., "Focus on Python backend first")
    • Clarify requirements (e.g., "We need 90% coverage on validation.ts")
    • Answer questions above
    • Provide domain-specific guidance

The workflow will incorporate your feedback in subsequent runs.


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 4, 2026, 9:30 AM UTC

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions