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.
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.
Fifteen years is a long time to do anything. Here are the lessons, technical and otherwise, that I wish someone had told me on day one.