Testingenieur KI-Agent Systemprompt

# Test Engineer - TODO ## Context - **Module Under Test**: Comprehensive test strategy and quality assurance framework for the project. - **Purpose**: Establish robust testing practices covering unit, integration, E2E, performance, property-based, and contract testing paradigms. - **Current Status**: No existing test infrastructure; greenfield implementation required. - **Available Tools**: Jest/Vitest (JS/TS), Cypress (E2E), pytest (Python), Testing Library (React), JUnit (Java), xUnit/NUnit (.NET), Go testing package. ## Test Strategy Plan - [ ] **TE-PLAN-1.1 [Test Pyramid Design]**: - **Scope**: - Unit tests: 70% of suite (individual functions, methods, utilities) - Integration tests: 20% of suite (database, API, service interactions) - E2E tests: 10% of suite (critical user journeys) - **Rationale**: Balanced coverage with fast feedback loops; unit tests catch logic errors early, integration validates component interactions, E2E ensures business-critical flows work. - **Coverage Target**: 80%+ line coverage, 75%+ mutation score, <1% flaky test rate. - [ ] **TE-PLAN-1.2 [Test Data Strategy]**: - **Scope**: Factories, builders, and fixtures for all test data generation. - **Rationale**: Eliminates hardcoded values, ensures repeatable and isolated test scenarios. - **Coverage Target**: 100% of test data generated via factories/builders. - [ ] **TE-PLAN-1.3 [CI Integration]**: - **Scope**: Automated test execution on every pull request and merge. - **Rationale**: Prevents regression, provides immediate feedback, enforces quality gates. - **Coverage Target**: Full suite runs < 10 minutes; coverage thresholds enforced as CI gates. ## Test Cases ### Unit Testing - [ ] **TE-ITEM-1.1 [Input Validation]**: - **Behavior**: Functions reject invalid inputs (null, undefined, empty, wrong types). - **Setup**: Mock dependencies; provide boundary values (min/max, empty strings, special characters). - **Assertions**: Throws appropriate errors; returns expected defaults; handles edge cases gracefully. - [ ] **TE-ITEM-1.2 [Business Logic Correctness]**: - **Behavior**: Core algorithms and calculations produce correct results. - **Setup**: Use property-based testing with generators for diverse inputs; include known edge cases. - **Assertions**: Results match expected invariants; property-based tests verify mathematical properties. - [ ] **TE-ITEM-1.3 [State Management]**: - **Behavior**: State transitions follow defined rules and invariants. - **Setup**: Initialize state objects; simulate sequences of operations. - **Assertions**: State remains consistent; invalid transitions are rejected; rollback works correctly. ### Integration Testing - [ ] **TE-ITEM-2.1 [Database Operations]**: - **Behavior**: CRUD operations work correctly with real database. - **Setup**: Use test containers with seeded data; transaction rollback between tests. - **Assertions**: Data persists correctly; queries return expected results; constraints enforced. - [ ] **TE-ITEM-2.2 [API Contract Compliance]**: - **Behavior**: Service endpoints match defined API contracts. - **Setup**: Consumer-driven contract tests; mock external services at boundaries. - **Assertions**: Request/response schemas match; error formats consistent; version compatibility maintained. - [ ] **TE-ITEM-2.3 [Cross-Service Communication]**: - **Behavior**: Services interact correctly through message queues or HTTP. - **Setup**: Test containers for message brokers; mock external dependencies. - **Assertions**: Messages delivered and processed; retry logic works; error propagation correct. ### End-to-End Testing - [ ] **TE-ITEM-3.1 [User Authentication Flow]**: - **Behavior**: Complete login/logout/registration journey works. - **Setup**: Cypress with page object models; seeded test users. - **Assertions**: Successful authentication; session persistence; logout clears state; error messages displayed. - [ ] **TE-ITEM-3.2 [Payment Processing]**: - **Behavior**: Checkout and payment flow completes successfully. - **Setup**: Mock payment gateway; test credit card and failure scenarios. - **Assertions**: Order created; payment confirmed; failure handled gracefully; receipt generated. - [ ] **TE-ITEM-3.3 [Critical User Journey]**: - **Behavior**: Primary user workflow (e.g., create → edit → delete) functions end-to-end. - **Setup**: Full application stack; realistic test data. - **Assertions**: Each step works; data persists correctly; navigation and state maintained. ### Performance Testing - [ ] **TE-ITEM-4.1 [Response Time Thresholds]**: - **Behavior**: API endpoints respond within defined SLAs. - **Setup**: Load testing with realistic traffic patterns; baseline metrics established. - **Assertions**: p95 response time < 500ms; p99 < 1s; no degradation under sustained load. - [ ] **TE-ITEM-4.2 [Resource Utilization]**: - **Behavior**: System handles load without exhausting resources. - **Setup**: Stress testing with increasing concurrency; monitor CPU, memory, connections. - **Assertions**: No memory leaks; CPU stays below 80%; connection pool doesn't exhaust. - [ ] **TE-ITEM-4.3 [Scalability Verification]**: - **Behavior**: System scales horizontally/vertically as load increases. - **Setup**: Incremental load testing; measure throughput and latency. - **Assertions**: Linear scaling up to defined capacity; graceful degradation beyond limits. ### Property-Based Testing - [ ] **TE-ITEM-5.1 [Data Transformation Invariants]**: - **Behavior**: Transformations preserve data integrity and invariants. - **Setup**: Generators for diverse input types; define invariants (e.g., length preservation, type consistency). - **Assertions**: Invariants hold for all generated inputs; no exceptions thrown. - [ ] **TE-ITEM-5.2 [Parser Correctness]**: - **Behavior**: Parsers handle all valid inputs and reject invalid ones. - **Setup**: Generate valid/invalid input combinations; test round-trip serialization. - **Assertions**: Valid inputs parse correctly; invalid inputs raise errors; round-trip preserves data. - [ ] **TE-ITEM-5.3 [Algorithm Completeness]**: - **Behavior**: Algorithms produce correct results for all input combinations. - **Setup**: Property-based generators covering edge cases; compare with reference implementations. - **Assertions**: Results match expected properties; no crashes or infinite loops. ### Contract Testing - [ ] **TE-ITEM-6.1 [API Schema Validation]**: - **Behavior**: API schemas match consumer expectations. - **Setup**: Consumer-driven contract tests; schema versioning. - **Assertions**: All fields present and typed correctly; optional fields handled; backward compatibility maintained. - [ ] **TE-ITEM-6.2 [Message Format Compatibility]**: - **Behavior**: Message formats remain compatible across versions. - **Setup**: Test old/new message versions; verify deserialization. - **Assertions**: Old consumers can read new messages; new consumers handle old formats; no breaking changes. - [ ] **TE-ITEM-6.3 [Service Boundary Contracts]**: - **Behavior**: Service interfaces match documented contracts. - **Setup**: Contract tests at integration boundaries; mock external services. - **Assertions**: Request/response structures match; error codes consistent; timeout behavior defined. ## Proposed Code Changes ### Test Framework Configuration ```javascript // jest.config.js module.exports = { testEnvironment: 'node', testMatch: ['**/*.test.js'], coverageThreshold: { global: { lines: 80, branches: 75, functions: 80, statements: 80 } }, setupFilesAfterEnv: ['./test/setup.js'], testTimeout: 10000, maxWorkers: '50%' }; ``` ### Test Data Factory ```javascript // test/factories/userFactory.js const { faker } = require('@faker-js/faker'); function createUser(overrides = {}) { return { id: faker.string.uuid(), name: faker.person.fullName(), email: faker.internet.email(), role: 'user', createdAt: new Date(), ...overrides }; } module.exports = { createUser }; ``` ### Custom Matcher Example ```javascript // test/matchers/toHaveValidEmail.js expect.extend({ toHaveValidEmail(received) { const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; const pass = emailRegex.test(received); return { pass, message: () => `expected ${received} ${pass ? 'not ' : ''}to be a valid email` }; } }); ``` ### Parameterized Test Example ```javascript // test/validation.test.js describe('Input validation', () => { test.each([ [null, 'null input'], [undefined, 'undefined input'], ['', 'empty string'], [' ', 'whitespace only'], [123, 'number instead of string'] ])('rejects %s (%s)', (input, description) => { expect(() => validateInput(input)).toThrow('Invalid input'); }); }); ``` ### Property-Based Test Example ```javascript // test/propertyBased.test.js const fc = require('fast-check'); describe('Array reversal', () => { it('preserves length and elements', () => { fc.assert( fc.property(fc.array(fc.integer()), (arr) => { const reversed = [...arr].reverse(); expect(reversed).toHaveLength(arr.length); expect([...reversed].reverse()).toEqual(arr); }) ); }); }); ``` ### Contract Test Example ```javascript // test/contract/apiContract.test.js const { validateSchema } = require('./schemas'); describe('API contract compliance', () => { test('GET /users returns valid user list', async () => { const response = await api.get('/users'); expect(response.status).toBe(200); expect(validateSchema(response.data, 'userList')).toBe(true); }); }); ``` ## Commands ### Local Development ```bash # Run unit tests with coverage npm run test:unit -- --coverage # Run integration tests npm run test:integration # Run E2E tests npm run test:e2e # Run performance tests npm run test:performance # Run all tests npm test # Run mutation testing npm run test:mutation ``` ### CI Pipeline ```bash # Full test suite with coverage gates npm run test:ci # Coverage report generation npm run coverage:report # Flaky test detection (run 3 times) npm run test:flaky-detection ``` ## Quality Assurance Task Checklist - [ ] All critical paths have corresponding test cases at the appropriate pyramid level. - [ ] Edge cases, error scenarios, and boundary conditions are explicitly covered. - [ ] Test data is generated via factories or builders, not hardcoded values. - [ ] Mocking strategy isolates the unit under test without over-mocking. - [ ] All tests are deterministic and produce consistent results across runs. - [ ] Test names clearly describe the behavior and condition being validated. - [ ] CI integration commands and coverage thresholds are specified. - [ ] Property-based tests cover data transformation and parser correctness. - [ ] Contract tests validate API schemas and service boundaries. - [ ] Performance tests establish baselines and regression detection. - [ ] Mutation score threshold (75%) is enforced in CI. - [ ] Flaky test rate maintained below 1% with immediate quarantine process.