Files
haproxy-openmanager/backend/tests
mustafa.ulukaya 8ac567dfe0 feat(vip): parse an existing keepalived.conf so a VIP can be adopted
Groundwork for adopting a hand-maintained keepalived setup into HA/VIP
management. The page is empty today because the flow is one-way: VIPs are
declared in OpenManager and pushed to the node, and nothing reads what is
already there.

The heartbeat cannot drive adoption. It carries two keepalived facts -
keepalive_state (MASTER/BACKUP, best-effort from logs) and keepalive_ip (the
first address grepped out of virtual_ipaddress) - while render_keepalived_conf
needs eleven: virtual_router_id, auth_pass, interface, priority, prefix_length,
advert_int, unicast peers, track_haproxy, role, address and name. Guessing the
rest is not a cosmetic risk: a wrong VRID puts the nodes in separate VRRP
domains and a wrong auth_pass makes them reject each other, and either way both
nodes claim the VIP. So the config itself has to be read.

Extracting the fields is the easy half. Adoption REPLACES the operator's file
with our render, so anything their file contains that the renderer cannot
reproduce would be destroyed on takeover - a notify_master failover hook, an LVS
virtual_server section, a sync group, a second address in one instance, a custom
track_script. The parser therefore also returns everything it could not model,
and build_adoption_candidate turns each entry into a blocker with the file's own
line number. Values that are unknowable rather than unreproducible block too: a
missing virtual_router_id, and a missing prefix length, because our renderer
always writes an explicit prefix and picking one would silently change a live
VIP's netmask. keepalived's own documented defaults (state BACKUP, priority 100,
advert_int 1) are applied but reported in `defaulted`, so the UI can say which
values were assumed rather than read.

Handles the layout variation real files have: nested braces, `#` and `!`
comments, blocks opened and closed on one line, quoted script paths containing
spaces, and several vrrp_instance blocks in one file.

A parse result carries auth_pass in cleartext, since that is the only way to
re-render an identical config, so it must never be logged - noted on every
function that returns one.

Tests pin each blocker and the layout variants, and include the invariant that
keeps the parser honest: a config the renderer itself produced must parse back
with zero blockers, so adding a directive to render_keepalived_conf without
teaching the parser fails the suite instead of making OpenManager's own output
look unadoptable. Verified by mutation - eight deliberate weakenings of the
safety checks are each caught by at least one test.

No endpoint, no schema change and no agent change yet; nothing calls this.
2026-08-11 01:18:49 +03:00
..
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00
2025-10-27 12:14:03 +03:00

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 constraints
  • test_apply_process.py - Critical apply process that manages entity states
  • test_entity_sync.py - Entity-specific agent sync calculations
  • test_haproxy_config.py - HAProxy configuration generation
  • test_auth.py - Authentication and authorization

Frontend Tests (frontend/src/components/__tests__/)

  • EntitySyncStatus.test.js - Agent sync status component
  • ApplyManagement.test.js - Apply management workflow
  • SSLManagement.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

  1. Apply Process - Prevents entity disappearance bugs
  2. Soft Delete Logic - Ensures proper unique constraint handling
  3. Entity Sync Calculations - Agent sync status accuracy
  4. Authentication/Authorization - Security validation

🟡 MEDIUM PRIORITY

  1. HAProxy Config Generation - Configuration correctness
  2. SSL Management - Certificate lifecycle
  3. Form Validations - Input validation

🟢 LOW PRIORITY

  1. UI Components - Visual behavior
  2. Utility Functions - Helper functions

Mock Strategy

Backend Mocking

  • Database connections: AsyncMock for 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

  1. Follow naming convention: test_*.py for backend, *.test.js for frontend
  2. Use appropriate fixtures: Leverage existing mock data
  3. Test edge cases: Include error scenarios and boundary conditions
  4. Update coverage: Ensure new code maintains coverage thresholds

Common Issues

Backend

  • Async tests: Use @pytest.mark.asyncio decorator
  • 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 fireEvent for 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)