mirror of
https://github.com/taylanbakircioglu/haproxy-openmanager.git
synced 2026-09-21 10:03:29 +00:00
4c84596215
Applies PR #59 by Mustafa Ulukaya (github.com/taylanbakircioglu/haproxy-openmanager/pull/59,
head ef26860) as authored, with only the merge conflicts resolved. Behavioural
gaps found in review are closed by the follow-up commits on this branch rather
than by rewriting the contribution.
One queryable timeline covering both directions: every inbound API call
(including GETs and 4xx/5xx) with user, client IP, status, duration and
redacted, size-capped bodies; and every outbound HTTP call the backend makes,
tagged with who it went to. Outbound rows inherit the inbound request's id, so
one operator action and the CA/DNS calls it triggered read as a single trace.
Conflict resolution (the branch was cut at v1.10.3, this tree is v1.10.14):
* SCHEMA_VERSION: 11 -> 12, NOT the 11 the branch proposed. 11 was taken in the
meantime by v1.10.4 (vip_discoveries). Landing this as 11 would be silently
inert: run_all_migrations() returns early on `applied_version >=
SCHEMA_VERSION`, so every database already at 11 skips the whole sequence and
gets neither request_logs nor the requestlog.* permissions, while a fresh
install gets both. The branch's own test asserts `>= 11`, so it still holds.
* services/acme_diagnostics.py: the branch instrumented a `session.head(...)`
probe, which is what that function did when it was cut. It has since become a
GET that classifies the response body, because a status code alone cannot
tell a working challenge endpoint from a SPA catch-all answering 200 with
index.html. Taking the branch's side would reintroduce that bug, so the GET
probe is kept and the span wraps it. The span records the classification, not
the body: `_PROBE_BODY_LIMIT` is 64 KB of a third party's page and storing it
would put an arbitrary remote document in the audit table per probed domain.
* backend/version.json, frontend/package.json: 1.11.0, release date moved to
the date this actually ships.
* README.md, UPGRADE_GUIDE.md: the v1.11.0 sections are added above the
existing entries; every note from v1.10.4 through v1.10.14 is preserved.
Schema: one new table (request_logs) plus its settings seed. No existing table
altered, no agent or rendered-config change. As with every SCHEMA_VERSION bump,
the four built-in roles are re-seeded to their defaults - export role
customizations before upgrading.
Kill switches: REQUEST_LOG_ENABLED=false (middleware never registered) or the
`enabled` toggle in Settings -> Request Log.
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)