Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:
The Percona Monitoring and Management (PMM) project employs a multi-tiered testing strategy designed to ensure the reliability of its complex, distributed architecture. The strategy encompasses isolated logic verification through unit tests, functional validation of service boundaries via API tests, and full-system validation through end-to-end (E2E) testing. This comprehensive approach ensures that components such as the PMM Server, PMM Client, and various database exporters function correctly both in isolation and as an integrated solution.
Sources: CONTRIBUTING.md:143-147, README.md:43-51
Testing Levels and Classification
PMM categorizes its verification efforts into three primary distinct levels. Each level target specific aspects of the codebase and requires different environments for execution.
Test Level Overview
| Test Type | Scope | Location | Execution Environment |
|---|---|---|---|
| Unit Tests | Individual functions/components | Component-specific repos | Local development environment |
| API Tests | Integrated service endpoints | api-tests/ directory | Active PMM Server container |
| End-to-End | UI and CLI workflows | percona/pmm-qa repo | Full PMM ecosystem |
Sources: CONTRIBUTING.md:148-164, api-tests/README.md:1-12
Unit Testing
Unit tests are decentralized; every repository within the PMM project maintains its own suite. These tests focus on internal logic, such as data processing constants for Query Analytics or individual server-side log reading functions.
- Frontend Unit Tests: Utilize
vitestand@testing-library/reactto mock hooks and providers (e.g.,useSnooze,updatesProvider) and verify component visibility conditions. - Backend Unit Tests: Written in Go, focusing on low-level utilities like zip file generation or log file line-limiting logic.
Sources: ui/apps/pmm/src/components/main/update-modal/UpdateModal.test.tsx:1-40, managed/services/server/logs_test.go:44-55, dashboards/pmm-app/src/pmm-qan/panel/QueryAnalytics.constants.test.tsx:1-10
API Testing
API tests validate the communication between clients and the PMM Server. These tests run against an active PMM Server instance and utilize generated clients (e.g., alerting_service) to perform operations like creating alert rules or templates.
The diagram shows the interaction between the API test suite and a running PMM Server instance.
Sources: api-tests/README.md:1-15, api-tests/alerting/alerting_test.go:42-60
Implementation Details
API Test Lifecycle
API tests follow a strict "revert changes" rule to ensure they can run in parallel on real systems. They typically involve:
- Setup: Authenticating using
PMM_SERVER_URL(format:https://user:pass@host). - Execution: Using
testing.Tandtestify/requirefor assertions. - Cleanup: Utilizing
t.Cleanupto remove test data (e.g., deleting Grafana folders or alerting templates) regardless of test outcome.
Sources: api-tests/README.md:46-51, api-tests/alerting/alerting_test.go:44-55
Development and Feature Builds
The "Feature Build" (FB) system is central to the testing strategy for new contributions. It allows developers to:
- Build all PMM components together into client and server containers.
- Receive automated test results before code is merged.
- Modify or add E2E tests corresponding to functional changes.
The diagram illustrates the workflow for Feature Builds and automated test feedback.
Sources: CONTRIBUTING.md:172-192, managed/CONTRIBUTING.md:10-25
Specialized Testing Environments
Devcontainer
For pmm-managed development, a Docker-based "devcontainer" is used. This environment mounts the source code and includes all necessary tools to run make test or make test-race (testing with the Go race detector).
| Make Target | Description |
|---|---|
make env-up | Starts the devcontainer with all required tools. |
make env TARGET=test | Runs the standard test suite inside the container. |
make env TARGET=check-all | Runs all checkers and linters. |
make env TARGET=test-race | Runs tests with the race detector enabled. |
Sources: managed/CONTRIBUTING.md:10-38, managed/CONTRIBUTING.md:118-125
UI and Dashboard Testing
Dashboards and frontend components utilize specific development environments:
- Docker Compose: Bundles tools to populate panels with sample data for Query Analytics (QAN).
- Yarn Dev: Used in conjunction with mapped volumes to
distfolders so Grafana can pick up frontend artifacts (panels and dashboards) in real-time.
Sources: dashboards/CONTRIBUTING.md:44-60, ui/apps/pmm/src/components/main/update-modal/UpdateModal.test.tsx:50-70
Conclusion
The PMM testing strategy prioritizes automated verification through standard CI pipelines and local development containers. By enforcing strict cleanup rules in API tests and providing a robust Feature Build system, the project maintains high code quality across its disparate backend and frontend components.