How to tell if you're testing the framework

A question popped up on our YouTube channel recently where the dev was questioning if a test I had shown was testing my application or just "testing the framework."

It's a great question, and one I see trip up developers at every experience level.

I have a simple trick for this. Take the test you're questioning, then see if you can comment out a chunk of application code and make the test fail.

It could be a single character, a method call, or an entire statement. If you can make the test fail with this approach, it's testing your logic and worth keeping. And if you can't make the test fail with anything short of ripping out the whole route, it's probably just testing the framework.

Let's consider a concrete example: route model binding.

If you hit /users/999 and that ID does not exist in the database, Laravel returns a 404. If you wrote a test to confirm that, there's no application code you can comment out to make that test fail. Laravel handles that behavior entirely on its own, and it already has tests for it.

But now let's consider a scenario where you've customized the route model binding to exclude inactive users:

// app/Models/User.php

public function resolveRouteBinding($value, $field = null): ?Model
{
    return $this->where('active', true)->findOrFail($value);
}

Testing that the ID for an inactive record returns a 404 is a test with real value. And now you can comment out your custom route model binding and watch the test fail.

You're testing a decision you made about how your application behaves.

Your test suite is most valuable when it focuses on your application code and configuration, and not built-in framework functionality.

Here to help,

Joel

P.S. Want to level up your testing skills and learn what's actually worth testing? Check out our testing workshop.