Ohhhh yes — Performance Testing.
Because "it works" means nothing if it takes longer to load than a USask student logging into PAWS on course registration day. 😩

Welcome to the part of regression testing that doesn’t care if your app works...
It cares how fast, how smooth, and how many people it can serve before it combusts harder than your group chat the night before a demo.

Let’s break it down, Prairie-style.

Performance Testing: When “It Works” Just Isn’t Good Enough Anymore

So you wrote a beautiful Java method.
It’s clean, elegant, and technically correct.
The tests pass. Your CI pipeline is green. You’re ready to vibe.

🚨 But wait.
Now your app slows down to a crawl when 20 users hit it.
Your beautifully engineered code takes 4 seconds to return a snowplow route.

“Bro… why does it lag harder than my Zoom call in a tunnel?”

Congratulations. You passed functional testing.
But you failed performance testing.

🏎️ What Is Performance Testing, Really?

Performance Testing is testing how fast, stable, and scalable your application behaves under various levels of workload.

Not whether the feature works, but:

🏃‍♂️ How quickly it works
🔄 How consistently it performs
🌪️ How it handles traffic spikes
💥 When it breaks under pressure

It’s the cardio of your code.
No one wants to test it, but everyone notices when it’s missing.

📦 Types of Performance Testing You Actually Need to Know

We’re not here to memorize definitions. We’re here to understand the vibes — and when to use what.

1. Load Testing

"Can it handle what it's supposed to handle?"

Test your app under expected usage.

E.g., if 200 students check snowplow times at once, does it survive?

2. Stress Testing

"What happens when we absolutely abuse this thing?"

Push your app beyond its limits to see where it crashes, and how gracefully (or not) it fails.

Think: last-minute course registration — USask servers know this test.

3. Spike Testing

"What if traffic suddenly jumps?"

Simulate sudden load surges (e.g., an influencer tweets your app link and now 10,000 people are trying to book the same bus route).

4. Soak Testing

"Can it run well over time?"

Let your app run under steady load for hours or days to detect memory leaks, slowdowns, and general exhaustion (just like students in Week 12).

🧪 Java + Performance Testing: Let’s Get Practical

If you’re in Java-land, you’ve got a few tools and tricks at your disposal.

✅ Use JMH (Java Microbenchmark Harness)

JMH is the go-to Java tool for microbenchmarking. It was literally written by the same people who built the JVM.

Here’s a tiny taste:

java
@Benchmark
public void testStringConcat() {
    String s = "";
    for (int i = 0; i < 1000; i++) {
        s += "a";
    }
}

This will measure the actual time it takes to run that method, down to nanoseconds.

💡 Use this when testing the performance of core methods or algorithms in your code.

✅ Use Load Testing Tools for Web Apps

Building a Java-based API, Spring Boot app, or any web service?

You’ll want tools like:

Apache JMeter – simulate traffic with custom requests
Gatling – modern load testing framework, super dev-friendly
Locust – Python-based but still great for simulating concurrent users

Example: JMeter simulating 500 concurrent requests to `/calculateRoute`

You can analyze:

Avg response time
Max response time
Throughput (requests/sec)
Error rate

💥 Performance in Regression Testing

Now here’s the kicker — what does all this have to do with regression testing?

Performance regressions are invisible to functional tests.

Your app can still return the right result and still be broken because it’s 3x slower now than it was before.

In regression testing, you’re not just checking:

“Does it work?”

You’re checking:

“Is it still fast, reliable, and scalable — just like last time?”

🧠 Common Performance Pitfalls (And How to Dodge Them Like Ice Patches on Campus)

❌ You only test performance locally

🙃 Bro, your laptop is not production. Simulate real-world usage.

❌ You don’t have baseline metrics

You can't detect a slowdown if you don’t know what “fast” looked like last week.

❌ You rely on eyeballing things

“It feels slower.”
Yeah? So does the Tim Hortons line. Measure it.

❌ You only run performance tests once

Performance isn’t a one-night stand. It’s a long-term commitment.

❌ You test performance after releasing

That’s not regression testing. That’s damage control.

🧙 Why Performance Tests Are Harder to Fake

Unlike unit tests where you can mock everything, performance tests:

Need real environments
Need real data sets
Need real concurrency and load simulation

You’re trying to break your own app — so you better do it before your users do.

📈 What to Measure

🕒 Response Time – How long did it take to return a result?
💪 Throughput – How many requests per second?
😤 Latency under Load – What’s the delay when 500 people show up?
🧠 CPU/Memory Usage – Is your app eating RAM like it’s pizza during finals?

🧪 Real-World Example (USask Transit App Style)

Let’s say you have this endpoint:

http
GET /api/route?start=PlaceA&end=PlaceB

It works fine with one user.

But during snow days when 2,000 students want to know if their bus is late?

That endpoint:

Starts lagging
Returns 500 errors
Or just straight up dies

A functional test won’t catch that. A performance regression test will.

You’d write a test that simulates 2,000 users hitting the endpoint and check:

Avg latency
% of failed requests
Max memory usage

🧠 TL;DR (Too Long, Didn’t Optimize)

✅ Performance testing checks speed, stability, and scalability
✅ It catches slowdowns that functional tests miss
✅ It includes Load, Stress, Spike, and Soak testing
✅ In regression testing, it ensures that performance hasn’t gotten worse
✅ Java has tools like JMH, JMeter, and Gatling
✅ Performance should be tested continuously — not once per semester

💡 Final Words from the CI Pipeline

Functional tests say: “This works.”
Performance tests ask: “But can it handle the heat?”

If you’re building something real — an API, a web app, a platform for Prairie bus routes or USask course alerts — performance is not a bonus. It’s a requirement.

So next time you refactor, optimize, or scale?
Make sure you’re not just passing tests — make sure you’re still fast enough to matter.

Testing

Content