torbo/flyer-crawler.projectium.com
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

more compliance
Some checks failed
Deploy to Test Environment / deploy-to-test (push) Failing after 58s
Details

Browse Source
This commit is contained in:
Torben Sorensen
2026-01-09 20:30:52 -08:00
parent b3efa3c756
commit 1480a73ab0
22 changed files with 1416 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

112
docs/adr/0010-testing-strategy-and-standards.md
View File

@@ -25,15 +25,15 @@ We will formalize the testing pyramid for the project, defining the role of each
### Testing Framework Stack
| Tool | Version | Purpose |
| ---- | ------- | ------- |
| Vitest | 4.0.15 | Test runner for all test types |
| @testing-library/react | 16.3.0 | React component testing |
| @testing-library/jest-dom | 6.9.1 | DOM assertion matchers |
| supertest | 7.1.4 | HTTP assertion library for API testing |
| msw | 2.12.3 | Mock Service Worker for network mocking |
| testcontainers | 11.8.1 | Database containerization (optional) |
| c8 + nyc | 10.1.3 / 17.1.0 | Coverage reporting |
| Tool | Version | Purpose |
| ------------------------- | --------------- | --------------------------------------- |
| Vitest | 4.0.15 | Test runner for all test types |
| @testing-library/react | 16.3.0 | React component testing |
| @testing-library/jest-dom | 6.9.1 | DOM assertion matchers |
| supertest | 7.1.4 | HTTP assertion library for API testing |
| msw | 2.12.3 | Mock Service Worker for network mocking |
| testcontainers | 11.8.1 | Database containerization (optional) |
| c8 + nyc | 10.1.3 / 17.1.0 | Coverage reporting |
### Test File Organization
@@ -61,12 +61,12 @@ src/
### Configuration Files
| Config | Environment | Purpose |
| ------ | ----------- | ------- |
| `vite.config.ts` | jsdom | Unit tests (React components, hooks) |
| `vitest.config.integration.ts` | node | Integration tests (API routes) |
| `vitest.config.e2e.ts` | node | E2E tests (full user flows) |
| `vitest.workspace.ts` | - | Orchestrates all test projects |
| Config | Environment | Purpose |
| ------------------------------ | ----------- | ------------------------------------ |
| `vite.config.ts` | jsdom | Unit tests (React components, hooks) |
| `vitest.config.integration.ts` | node | Integration tests (API routes) |
| `vitest.config.e2e.ts` | node | E2E tests (full user flows) |
| `vitest.workspace.ts` | - | Orchestrates all test projects |
### Test Pyramid
@@ -150,9 +150,7 @@ describe('Auth API', () => {
});
it('GET /api/auth/me returns user profile', async () => {
const response = await request
.get('/api/auth/me')
.set('Authorization', `Bearer ${authToken}`);
const response = await request.get('/api/auth/me').set('Authorization', `Bearer ${authToken}`);
expect(response.status).toBe(200);
expect(response.body.user.email).toBeDefined();
@@ -212,13 +210,13 @@ it('creates flyer with items', () => {
### Test Utilities
| Utility | Purpose |
| ------- | ------- |
| Utility | Purpose |
| ----------------------- | ------------------------------------------ |
| `renderWithProviders()` | Wrap components with AppProviders + Router |
| `createAndLoginUser()` | Create user and return auth token |
| `cleanupDb()` | Database cleanup respecting FK constraints |
| `createTestApp()` | Create Express app for route testing |
| `poll()` | Polling utility for async operations |
| `createAndLoginUser()` | Create user and return auth token |
| `cleanupDb()` | Database cleanup respecting FK constraints |
| `createTestApp()` | Create Express app for route testing |
| `poll()` | Polling utility for async operations |
### Coverage Configuration
@@ -257,11 +255,11 @@ npm run clean
### Test Timeouts
| Test Type | Timeout | Rationale |
| --------- | ------- | --------- |
| Unit | 5 seconds | Fast, isolated tests |
| Integration | 60 seconds | AI service calls, DB operations |
| E2E | 120 seconds | Full user flow with multiple API calls |
| Test Type | Timeout | Rationale |
| ----------- | ----------- | -------------------------------------- |
| Unit | 5 seconds | Fast, isolated tests |
| Integration | 60 seconds | AI service calls, DB operations |
| E2E | 120 seconds | Full user flow with multiple API calls |
## Best Practices
@@ -298,6 +296,62 @@ npm run clean
2. **Integration tests**: Mock only external APIs (AI services)
3. **E2E tests**: Minimal mocking, use real services where possible
### Testing Code Smells
**When testing requires any of the following patterns, treat it as a code smell indicating the production code needs refactoring:**
1. **Capturing callbacks through mocks**: If you need to capture a callback passed to a mock and manually invoke it to test behavior, the code under test likely has poor separation of concerns.
2. **Complex module resets**: If tests require `vi.resetModules()`, `vi.doMock()`, or careful ordering of mock setup to work correctly, the module likely has problematic initialization or hidden global state.
3. **Indirect verification**: If you can only verify behavior by checking that internal mocks were called with specific arguments (rather than asserting on direct outputs), the code likely lacks proper return values or has side effects that should be explicit.
4. **Excessive mock setup**: If setting up mocks requires more lines than the actual test assertions, consider whether the code under test has too many dependencies or responsibilities.
**The Fix**: Rather than writing complex test scaffolding, refactor the production code to be more testable:
- Extract pure functions that can be tested with simple input/output assertions
- Use dependency injection to make dependencies explicit and easily replaceable
- Return values from functions instead of relying on side effects
- Split modules with complex initialization into smaller, focused units
- Make async flows explicit and controllable rather than callback-based
**Example anti-pattern**:
```typescript
// BAD: Capturing callback to test behavior
const capturedCallback = vi.fn();
mockService.onEvent.mockImplementation((cb) => {
capturedCallback = cb;
});
await initializeModule();
capturedCallback('test-data'); // Manually triggering to test
expect(mockOtherService.process).toHaveBeenCalledWith('test-data');
```
**Example preferred pattern**:
```typescript
// GOOD: Direct input/output testing
const result = await processEvent('test-data');
expect(result).toEqual({ processed: true, data: 'test-data' });
```
### Known Code Smell Violations (Technical Debt)
The following files contain acknowledged code smell violations that are deferred for future refactoring:
| File | Violations | Rationale for Deferral |
| ------------------------------------------------------ | ------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
| `src/services/queueService.workers.test.ts` | Callback capture, `vi.resetModules()`, excessive setup | BullMQ workers instantiate at module load; business logic is tested via service classes |
| `src/services/workers.server.test.ts` | `vi.resetModules()` | Same as above - worker wiring tests |
| `src/services/queues.server.test.ts` | `vi.resetModules()` | Queue instantiation at module load |
| `src/App.test.tsx` | Callback capture, excessive setup | Component integration test; refactoring would require significant UI architecture changes |
| `src/features/voice-assistant/VoiceAssistant.test.tsx` | Multiple callback captures | WebSocket/audio APIs are inherently callback-based |
| `src/services/aiService.server.test.ts` | Multiple `vi.resetModules()` | AI service initialization complexity |
**Policy**: New code should follow the code smell guidelines. These existing violations are tracked here and will be addressed when the underlying modules are refactored or replaced.
## Key Files
- `vite.config.ts` - Unit test configuration