Whether you’re new to DevOps or an experienced hand, sometimes it’s a challenge to explain the difference between performance testing and performance tuning. It happens to us, too. Here’s how we describe understanding performance testing and performance tuning.
For the most accurate load test, best practices (and common sense) dictate that your testing environment be as close to real production and user behavior as possible. We get it, though! Best practices don’t necessarily reflect the challenge and rush of a real development pipeline. For example, if you’re like us, you likely have a much larger amount of data in your production environment than in your testing and staging environment. A detailed, extremely realistic testing database is nice, but perhaps not necessary. Let us explain.
As with so many things in life, best practices in load testing apply well to optimizing your work and your workday. You can find productivity hacks anywhere, including in your load testing habits. Here’s our take:
The concept of load testing seems simple. You just run a test against your app, API or site and see how it performs under a simulated user load. But the reality is slightly more complex. There are three load tests you must run to optimize performance.
We believe load tests are your performance guardians. If the minimum performance levels you’ve set aren’t met, a build should fail. Load testing is as important as unit and functional testing, and we run our load tests with every nightly build. No matter how small our code changes are, we use load tests as safety mechanisms to make sure we didn’t accidentally torpedo our performance with a small change. (Nowadays systems, apps and dependencies can be so complex it’s difficult to predict how any change will affect the rest of the system.)
For all you CircleCI users out there, we have created a simple step by step page on how to integrate k6 in your build setup.