-
Notifications
You must be signed in to change notification settings - Fork 0
Daily Test Coverage ImproverResearch and Plan #14
Description
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-v8provider - Python: pytest 9.0.2 with pytest-cov 7.0.0
- Component Testing:
@testing-library/react16.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/deletionsrc/utils/validation.ts(216 lines) - Email/phone/URL validation, XSS prevention, rate limiting, data retentionsrc/components/ContactForm.tsx(183 lines) - React form with WCAG 2.1 AA accessibilityfrontend/components/Header.tsx(14 lines) - Simple header componentmain.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 retentionbackend/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:
- ❌ JavaScript tests: Some tests may be failing or incomplete
- ❌ Python tests: Import errors in test files (trying to import non-existent classes)
⚠️ 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:
- Sets up Node.js 18 and Python 3.11 environments
- Installs testing dependencies (Vitest, pytest, coverage tools)
- Creates Vitest configuration for JavaScript coverage
- Runs JavaScript/TypeScript tests with coverage
- Runs Python tests with coverage
- Generates combined coverage reports
- 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.ymlPhase 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 protectionlogAuditEvent()- Compliance audit logging (critical for GDPR)exportUserData()- GDPR Right to Data PortabilitydeleteUserData()- 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 validationvalidateURL()- URL validation with protocol restrictionshashSensitiveData()- Privacy compliance hashingRateLimiterclass - Abuse prevention (needs comprehensive testing)DataRetentionManagerclass - 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:
- Fix import errors in existing test file
- Expand tests for:
ContactFormHandler.process_submission()- End-to-end submission flowContactFormHandler.check_rate_limit()- Rate limiting logicDataRetentionManager- 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 endpointcreate_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
-
TDD Email Validation: Should I implement
src/utils/emailValidation.tsbased on the existing 426-line test suite, or are those tests intended for a different purpose? -
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?
-
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?
-
Performance Testing: Should I add performance/load testing for:
- Rate limiting effectiveness?
- Form submission under load?
- API endpoint response times?
-
Security Testing: Should I add explicit security test suites for:
- XSS prevention verification?
- SQL injection prevention?
- CSRF protection validation?
-
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-websiteWhat Happens Next
-
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
-
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
-
Repeat Mode: If running with
--repeat, the workflow will automatically continue to Phase 3 and make iterative improvements without waiting for human review. -
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