You are tasked with adding comprehensive testing. This testing implementation should improve code coverage and quality assurance while integrating seamlessly with existing development workflows.
**TESTING SCOPE & OBJECTIVES**
- **What specific components or areas need testing coverage?**: *Identify the modules, functions, classes, or features that currently lack adequate test coverage.*
- **What is the current testing state of the codebase?**: *Describe existing test suites, current coverage percentage, and any testing infrastructure already in place.*
- **What types of tests need to be implemented?**: *Specify the mix of unit tests, integration tests, component tests, or end-to-end tests required.*
- **What is the target code coverage percentage or quality threshold?**: *Define specific coverage goals or quality metrics that should be achieved.*
- **Are there any critical user flows or business logic that must be thoroughly tested?**: *Identify high-priority scenarios that require comprehensive test coverage.*
**SYSTEM BOUNDARIES**
- **What boundaries should we set for Blitzy during this testing implementation?**: *Define the limits within which Blitzy should operate (e.g., "only add tests for the /src/services directory" or "focus on unit tests for business logic components only").*
- **What components or layers of the system will be covered by these tests?**: *Identify the scope across frontend components, backend services, data access layers, and utility functions.*
- **What existing functionality must remain completely untouched?**: *Identify critical features, workflows, and capabilities that must continue working exactly as they do today.*
- **What existing interfaces, APIs, or contracts must remain unchanged?**: *List any external or internal interfaces that cannot be modified during test implementation.*
- **What parts of the codebase should be excluded from testing?**: *Specify any legacy code, third-party integrations, or areas that should not be tested.*
**TECHNICAL IMPLEMENTATION**
- **What testing framework and tools should be used?**: *Specify the preferred testing libraries, runners, assertion libraries, and mocking frameworks for the project.*
- **How should test files be organized and structured?**: *Describe naming conventions, directory structure, and organization patterns for test files.*
- **What mocking or stubbing strategies should be employed?**: *Define how external dependencies, APIs, databases, or services should be mocked in tests.*
- **How should test data and fixtures be managed?**: *Specify approaches for test data setup, factories, fixtures, or database seeding.*
- **What testing utilities or helpers need to be created?**: *Identify reusable test utilities, custom matchers, or setup functions that would benefit multiple test files.*
**TEST COVERAGE STRATEGY**
- **What specific scenarios and edge cases should be covered?**: *List the types of test cases needed including happy paths, error conditions, boundary values, and edge cases.*
- **How should complex business logic be tested?**: *Define approaches for testing workflows, state machines, calculations, or multi-step processes.*
- **What error handling and exception scenarios need coverage?**: *Identify error conditions, validation failures, and exception paths that should be tested.*
- **How should asynchronous code and timing-dependent logic be tested?**: *Specify strategies for testing promises, callbacks, timers, or event-driven code.*
**TESTING INTEGRATION & WORKFLOW**
- **How should these tests integrate with existing CI/CD pipelines?**: *Specify how new tests should be incorporated into build processes, deployment gates, and automated workflows.*
- **What test execution and reporting requirements exist?**: *Define how tests should be run, what output formats are needed, and how results should be reported.*
- **How should test performance and execution time be managed?**: *Identify any requirements for test speed, parallel execution, or performance optimization.*
- **What documentation or guidelines should accompany the test implementation?**: *Specify any testing documentation, guidelines, or onboarding materials needed for the team.*
**QUALITY ASSURANCE**
- **What criteria will determine that testing implementation is complete and effective?**: *Define success metrics, coverage thresholds, and quality gates for the testing work.*
- **How will test reliability and maintainability be ensured?**: *Specify approaches for preventing flaky tests, ensuring test stability, and maintaining test code quality.*
- **What validation process will confirm tests are working correctly?**: *Describe how test effectiveness will be verified, including failure scenario testing.*
**MINIMAL CHANGE CLAUSE & TESTING DISCIPLINE GUIDELINES** *(Recommended for most Testing Implementations)*
- **IMPORTANT: Make only the changes that are absolutely necessary to implement comprehensive testing coverage.**
- Focus specifically on adding test files and minimal test infrastructure without modifying existing production code unless required for testability. Your goal is to achieve thorough test coverage while preserving current functionality and avoiding unnecessary refactoring.
- **IMPORTANT: Follow these Testing Discipline Guidelines to ensure focused test development:**
- Add only the minimal necessary changes to existing code to enable testing (e.g., dependency injection, visibility adjustments)
- Do not refactor production code unless absolutely required for testability
- Do not modify existing interfaces or behaviors unless specified for testing purposes
- Isolate all test code in dedicated test files and directories
- Create test utilities and helpers in separate files to avoid cluttering production code
- Document any changes made to production code with clear comments explaining testing requirements
- When multiple testing approaches exist, choose the one that requires the least modification to existing code
- If you identify code quality issues during testing, note them but do not fix unless required for test implementation
