mirror of
https://github.com/taylanbakircioglu/haproxy-openmanager.git
synced 2026-09-12 05:48:58 +00:00
taylanbakircioglu
9d7a142cfa
My own test, and it broke the release build. CI reported `assert 239800 == 0` on the very commit that was supposed to ship v1.11.0, so no image was pushed and the tag and release were never cut. The test drained a 50-row queue with `batch_size=100` and `flush_ms=10`, then asserted the byte counter was back to zero. `_collect()` stops at whichever comes first, `batch_size` rows or the flush deadline - and with a batch size larger than the row count, the deadline is the only thing that can end it. It was measuring the scheduler, not the sink. The arithmetic is exact: a row here weighs 1400 + 4096 + 4096 = 9592 bytes, and 239 800 is 25 of them. `_collect()` returned half the queue because 25 iterations of `asyncio.wait_for` were enough to exhaust 10 ms on that runner. The workflow builds `linux/amd64,linux/arm64`, so one of the two runs under qemu emulation; a local `docker build` compiles the native platform only and never sees that path. I could not reproduce the failure even building both platforms here - this machine fits 49 iterations inside 10 ms - which is the point: a test whose result depends on how fast the host is will pass everywhere it is convenient and fail where it matters. Fixed structurally rather than by widening the window: `batch_size` now EQUALS the row count, so the collect loop exits on the count and never consults the deadline at all. The flush window is generous as a backstop, the drain runs in a loop instead of a single call, and the row count is asserted on the way in and on the way out so a future change cannot make it vacuous. Verified on both platforms the workflow builds: 1667 passed / 152 skipped on linux/arm64 and on linux/amd64 under emulation. No production code changes.
HAProxy Management UI - Unit Tests
Overview
Comprehensive unit test suite for the HAProxy Management UI backend, covering critical business logic and ensuring reliability.
Test Structure
Backend Tests (backend/tests/)
test_soft_delete.py- Soft delete functionality and unique constraintstest_apply_process.py- Critical apply process that manages entity statestest_entity_sync.py- Entity-specific agent sync calculationstest_haproxy_config.py- HAProxy configuration generationtest_auth.py- Authentication and authorization
Frontend Tests (frontend/src/components/__tests__/)
EntitySyncStatus.test.js- Agent sync status componentApplyManagement.test.js- Apply management workflowSSLManagement.test.js- SSL certificate management
Running Tests
Backend Tests
# Install test dependencies
pip install -r backend/requirements-test.txt
# Run all tests
pytest
# Run specific test file
pytest backend/tests/test_apply_process.py
# Run with coverage
pytest --cov=backend --cov-report=html
# Run specific test
pytest backend/tests/test_soft_delete.py::TestSoftDeleteUniqueConstraints::test_backend_soft_delete_allows_name_reuse
Frontend Tests
# Run all frontend tests
npm test
# Run with coverage
npm run test:coverage
# Run in CI mode
npm run test:ci
Test Coverage Goals
- Backend: 70% minimum coverage
- Frontend: 70% minimum coverage
- Critical paths: 90%+ coverage (apply process, soft delete, entity sync)
Critical Test Areas
🔴 HIGH PRIORITY
- Apply Process - Prevents entity disappearance bugs
- Soft Delete Logic - Ensures proper unique constraint handling
- Entity Sync Calculations - Agent sync status accuracy
- Authentication/Authorization - Security validation
🟡 MEDIUM PRIORITY
- HAProxy Config Generation - Configuration correctness
- SSL Management - Certificate lifecycle
- Form Validations - Input validation
🟢 LOW PRIORITY
- UI Components - Visual behavior
- Utility Functions - Helper functions
Mock Strategy
Backend Mocking
- Database connections:
AsyncMockfor database operations - External APIs: Mock HTTP calls
- File operations: Mock file system access
Frontend Mocking
- API calls: Mock axios requests
- Ant Design components: Mock component behavior
- Context providers: Mock React contexts
Test Data
All tests use consistent mock data from conftest.py:
- Sample clusters, backends, frontends
- Mock users and authentication
- Config versions and SSL certificates
Debugging Tests
# Run with verbose output
pytest -v -s
# Run specific failing test
pytest backend/tests/test_apply_process.py::TestApplyProcess::test_apply_process_preserves_active_entities -v -s
# Drop into debugger on failure
pytest --pdb
Integration with CI/CD
Tests are designed to run in Azure DevOps pipeline:
# Example pipeline step
- script: |
pip install -r backend/requirements-test.txt
pytest --cov=backend --cov-report=xml
displayName: 'Run Backend Tests'
- script: |
npm ci
npm run test:ci
displayName: 'Run Frontend Tests'
Adding New Tests
- Follow naming convention:
test_*.pyfor backend,*.test.jsfor frontend - Use appropriate fixtures: Leverage existing mock data
- Test edge cases: Include error scenarios and boundary conditions
- Update coverage: Ensure new code maintains coverage thresholds
Common Issues
Backend
- Async tests: Use
@pytest.mark.asynciodecorator - Database mocking: Ensure proper mock setup for database operations
- Import paths: Use relative imports for testable modules
Frontend
- Component rendering: Wait for async operations with
waitFor - Event simulation: Use
fireEventfor user interactions - Mock cleanup: Clear mocks between tests with
jest.clearAllMocks()
Test Philosophy
These tests focus on:
- Business logic correctness over implementation details
- Critical path coverage over 100% coverage
- Regression prevention based on actual bugs encountered
- Maintainability with clear, readable test cases
The test suite is designed to catch the types of bugs we've actually encountered in production, particularly around the apply process and soft delete behavior.
Test deployment trigger - $(date)