Performance vs other testing
Most engineering teams already run some combination of unit tests, integration tests, and end-to-end functional tests. Performance testing sits alongside these disciplines — it does not replace them, and they do not replace it. Understanding the boundary helps you decide when to reach for MaxoPerf and when to stay in your existing test harness.
The testing landscape
Section titled “The testing landscape”| Type | Primary question | Typical tool | What it misses |
|---|---|---|---|
| Unit test | ”Does this function return the right value?” | Jest, pytest, JUnit | System behavior under load; integration points |
| Integration test | ”Do these services talk to each other correctly?” | Supertest, Testcontainers | Concurrent users; sustained traffic; resource exhaustion |
| End-to-end / functional test | ”Does the user flow work in a real browser?” | Playwright, Cypress, Selenium | Response time at scale; capacity; stability over time |
| Performance / load test | ”How does the system behave under N concurrent users?” | MaxoPerf (Taurus/JMeter/k6) | Correctness of individual responses; business-logic assertions |
| Security / penetration test | ”Can an attacker exploit the system?” | OWASP ZAP, custom tools | Performance under legitimate load |
| User acceptance test (UAT) | “Does the product satisfy the business requirement?” | Manual, sometimes Playwright | Scale, capacity, latency at load |
What each discipline owns
Section titled “What each discipline owns”Functional tests own correctness
Section titled “Functional tests own correctness”A functional test asks “does this endpoint return the right JSON with the right status code?” A load test asks “does this endpoint return any response within 500 ms when 300 users are hitting it simultaneously?” They measure different dimensions of the same system.
This means a passing test suite does not tell you your system is fast. It tells you it is correct. You need both.
Performance tests own behavior at scale
Section titled “Performance tests own behavior at scale”A single-user integration test might show a 20 ms response time. The same endpoint at 500 concurrent users might show 2 000 ms — or start returning 503s. That behavior only surfaces under load. No amount of unit or integration testing will predict it.
MaxoPerf is designed specifically for this dimension: sustained concurrent load, distributed across one or more locations, with per-percentile latency reporting.
Security tests and performance tests overlap at one point
Section titled “Security tests and performance tests overlap at one point”A distributed denial-of-service (DDoS) attack is effectively load at malicious scale. A performance test is load at authorized, controlled scale. The technical shape is similar; the intent and authorization are completely different. See Choosing safe test environments for the authorization and blast-radius considerations MaxoPerf requires.
UAT and performance sometimes intersect
Section titled “UAT and performance sometimes intersect”User acceptance testing confirms a product meets its specification. Performance requirements are often part of that specification (e.g., “checkout must complete in under 2 seconds at 95th percentile during peak load”). When UAT includes performance acceptance criteria, MaxoPerf runs provide the evidence — the SLO comparison in a finished run-detail page maps directly to the acceptance criterion.
How MaxoPerf fits in your CI/CD pipeline
Section titled “How MaxoPerf fits in your CI/CD pipeline”Functional tests typically run in the CI pipeline on every commit. Performance tests run on a different cadence:
| Cadence | What to run | Why |
|---|---|---|
| Every commit / PR (fast) | Smoke test (1-5 VUs, 30s) | Confirm test setup is still valid; catch critical regressions early. |
| Nightly / on main merge | Load test (target load profile, 10-30 min) | Baseline comparison; catch regressions before they reach staging. |
| Before each release | Stress test + spike test | Confirm capacity under peak load; validate recovery behavior. |
| Weekly or monthly | Soak test (hours) | Detect slow leaks, resource exhaustion, and long-running anomalies. |
The CI-gated performance test recipe shows how to trigger a MaxoPerf run from GitHub Actions and fail the pipeline when SLO thresholds are breached.
Do / don’t
Section titled “Do / don’t”| Do | Don’t |
|---|---|
| Run functional tests first; performance tests assume a correct system. | Use load testing to validate individual-response correctness — that is what assertions in your functional suite are for. |
| Treat performance tests as a separate, complementary discipline with its own cadence. | Skip performance testing because you have good unit coverage. Unit coverage says nothing about scale. |
| Use the same target environment for both functional E2E and performance tests (staging is standard). | Run performance tests in the same CI slot as unit tests — they have very different resource and time budgets. |
Where to go next
Section titled “Where to go next”- Core metrics explained — the metrics that performance tests produce and what each one tells you.
- Choosing safe test environments — staging vs production; authorization and blast-radius guidance.
- CI-gated performance test — integrate MaxoPerf into your CI/CD pipeline.
- What is performance testing? — the goals and lifecycle of a performance test.