fetch_ml

History

Jeremie Fraeys 0687ffa21f refactor: move queue spec tests to tests/unit/ and fix test failures - Move queue_spec_test.go from internal/queue/ to tests/unit/queue/ - Update imports to use github.com/jfraeys/fetch_ml/internal/queue - Remove duplicate docker-compose.dev.yml from root (exists in deployments/) - Fix spec tests: add required Status field, JobName field - Fix loop variable capture in priority ordering test - Fix missing closing brace between test functions - Fix existing queue_test.go: change 50ms to 1s for Redis min duration All tests pass: go test ./tests/unit/queue/...		2026-02-18 15:45:30 -05:00
..
benchmarks	test(benchmarks): add tolerance to response packet regression test	2026-02-18 12:45:40 -05:00
chaos	test: add comprehensive test coverage and command improvements	2026-02-16 20:38:15 -05:00
e2e	refactor(dependency-hygiene): Fix Redis leak, simplify TUI wrapper, clean go.mod	2026-02-17 21:13:49 -05:00
fixtures	test: expand unit/integration/e2e coverage for new worker/api behavior	2026-01-05 12:31:36 -05:00
integration	test(integration): add websocket queue and hash benchmarks	2026-02-18 12:46:06 -05:00
load	chore(cleanup): remove legacy artifacts and add tooling configs	2026-02-12 12:06:09 -05:00
scripts	test: implement comprehensive test suite with multiple test types	2025-12-04 16:55:13 -05:00
unit	refactor: move queue spec tests to tests/unit/ and fix test failures	2026-02-18 15:45:30 -05:00
README.md	test: expand unit/integration/e2e coverage for new worker/api behavior	2026-01-05 12:31:36 -05:00

README.md

Test Categories

1. Unit Tests (`unit/`)

Purpose: Test individual functions and components in isolation
Scope: Small, fast tests for specific functionality
Languages: Go and Zig tests
Usage: make test-unit

2. Integration Tests (`integration/`)

Purpose: Test component interactions and system integration
Scope: Multiple components working together
Dependencies: Requires Redis, database
Usage: make test-integration

3. End-to-End Tests (`e2e/`)

Purpose: Test complete user workflows and system behavior
Scope: Full system from user perspective
Dependencies: Complete system setup
Usage: make test-e2e

Note: Podman-based E2E (TestPodmanIntegration) is opt-in because it builds/runs containers. Enable it with FETCH_ML_E2E_PODMAN=1 go test ./tests/e2e/....

4. Performance Tests (`benchmarks/`)

Purpose: Measure performance characteristics and identify bottlenecks
Scope: API endpoints, ML experiments, payload handling
Metrics: Latency, throughput, memory usage
Usage: make benchmark

5. Load Tests (`load/`)

Purpose: Test system behavior under high load
Scope: Concurrent users, stress testing, spike testing
Scenarios: Light, medium, heavy load patterns
Usage: make load-test

6. Chaos Tests (`chaos/`)

Purpose: Test system resilience and failure recovery
Scope: Database failures, Redis failures, network issues
Scenarios: Connection failures, resource exhaustion, high concurrency
Usage: make chaos-test

Test Execution

Quick Test Commands

make test              # Run all tests
make test-unit         # Unit tests only
make test-integration  # Integration tests only
make test-e2e         # End-to-end tests only
make test-coverage    # All tests with coverage report

Performance Testing Commands

make benchmark         # Run performance benchmarks
make load-test         # Run load testing suite
make chaos-test        # Run chaos engineering tests
make tech-excellence   # Run complete technical excellence suite

Individual Test Execution

# Run specific benchmark
go test -bench=BenchmarkAPIServer ./tests/benchmarks/

# Run specific chaos test
go test -v ./tests/chaos/ -run TestChaosTestSuite

# Run with coverage
go test -cover ./tests/unit/

Test Dependencies

Required Services

Redis: Required for integration, performance, and chaos tests
Database: SQLite for local, PostgreSQL for production-like tests
Docker/Podman: For container-based tests

Test Configuration

Test databases use isolated Redis DB numbers (4-7)
Temporary directories used for file-based tests
Test servers use random ports to avoid conflicts

Best Practices

Writing Tests

Unit Tests: Test single functions, mock external dependencies
Integration Tests: Test real component interactions
Performance Tests: Use testing.B for benchmarks, include memory stats
Chaos Tests: Simulate realistic failure scenarios

Test Organization

Package Naming: Use descriptive package names (benchmarks, chaos, etc.)
File Naming: Use *_test.go suffix, descriptive names
Test Functions: Use Test* for unit tests, Benchmark* for performance

Cleanup

Resources: Close database connections, Redis clients
Temp Files: Use t.TempDir() for temporary files
Test Data: Clean up Redis test databases after tests

Technical Excellence Features

The test suite includes advanced testing capabilities:

Performance Regression Detection: Automated detection of performance degradations
Chaos Engineering: System resilience testing under failure conditions
Load Testing: High-concurrency and stress testing scenarios
Profiling Tools: CPU, memory, and performance profiling
Architecture Decision Records: Documented technical decisions

CI/CD Integration

All tests are integrated into the CI/CD pipeline:

Unit tests run on every commit
Integration tests run on PRs
Performance tests run nightly
Chaos tests run before releases

Troubleshooting

Common Issues

Redis Connection: Ensure Redis is running for integration tests
Port Conflicts: Tests use random ports, but conflicts can occur
Resource Limits: Chaos tests may hit system resource limits
Test Isolation: Ensure tests don't interfere with each other

Debug Tips

Use -v flag for verbose output
Use -run flag to run specific tests
Check test logs for detailed error information
Use make test-coverage for coverage analysis