How I Decide What to Test in Laravel
I start with what a test should prove, then choose the boundary that can prove it. This is how I separate Unit, Integration, Feature and browser tests without making every test do the same job.
I start with what a test should prove, then choose the boundary that can prove it. This is how I separate Unit, Integration, Feature and browser tests without making every test do the same job.
I separate who a user is from what they're allowed to do. Gates and policies organize the permission rules, but the server still has to enforce them before the operation runs.
I use queues to move work out of the request, but dispatching a job is only the handoff. I still need a worker, a safe retry, and a way to know whether the work finished.
I follow a request from Laravel's entry point to the route handler and back through middleware. Knowing where it can stop gives me a better place to start debugging.
AI agents write plausible Laravel. Getting them to write your Laravel takes context that lives in the repo, not better prompts. This is the setup I use on this site.
After years of iteration, this is the project structure I reach for on every new Laravel app. Actions, services, form requests, and Pest tests. All of it.
Every year someone declares PHP dead and Laravel irrelevant. Every year I start another Laravel project. Here's why I'm not switching.
I grew up in Kansas, discovered the web in the late 2000s, and somehow ended up writing code full-time in Florida. This is that story.
After 15 years of building things with PHP and Laravel (with two podcasts and a YouTube channel on the way), I figured it was time to start writing things down. Here's why.