A Laravel feature from structure to tests
Three articles on organizing a feature, enforcing permissions and choosing useful tests.
Where code belongs, who can run it, and what a test should prove.
Published
Thanks for being here. For this first newsletter, I’ve picked three articles that follow a feature from its place in the application to the tests around it.
Start With Where the Code Belongs
A controller is easier to follow when it hands validation and the operation itself to code with a clear responsibility. In this article, I walk through the structure I use, including Form Requests, Actions and Queries.
These are conventions I use when they help. Laravel doesn’t require every feature to have every layer.
Read How I Structure Every Laravel Project
Check Who May Run It
Once the operation has a home, I want to know who’s allowed to call it. Signing in doesn’t automatically give someone permission to change a record, and hiding a button doesn’t enforce that rule.
This article covers how I organize permission checks with gates and policies, then enforce them on the server before the operation runs.
Read How I Handle Authorization in Laravel
Decide What the Test Should Prove
For a protected write, I want a test that checks both the denied response and the record staying unchanged. That gives me something specific to prove before I choose a test boundary.
I work through Unit, Integration, Feature and browser tests, including what a fake leaves out and when another test catches a different failure.
Read How I Decide What to Test in Laravel
Pick one write operation in your app. Trace where its work happens, find the permission check, and look at what the test asserts after a denied request. That’s a useful place to start.