Hardcoding job labels in the UI is a maintenance problem. As soon as you rename a job class or change its behaviour, your UI copy is stale. Store the label where it belongs: on the job.
Interfaces in Laravel jobs aren't just structural. They let you make guarantees at the point of persistence โ when you write to the database, you know the data is there.
A ServerJobInterface with title() and description() methods enforces a contract. Any job that implements it must provide both. No guessing whether the data exists when you go to store it.
Do you store metadata alongside your queued jobs, or do you reconstruct job context from the payload at render time? Curious what people are actually doing in production.
Two new columns on the server_tasks table: title and description. Simple migration, but it unlocks dynamic job labelling across your entire queue pipeline.
Storing jobs in the database gives you more than state tracking. You can attach metadata โ title, description โ to each task and use it directly in your UI without hardcoding anything.
This week was about getting Dusk's database setup right โ separate MySQL database, correct env file, migrations running cleanly. Easy to skip early on, annoying to fix later. Full episode if you missed it. https://t.co/wloDnSwPKt
Spent the week on Dusk database isolation โ why in-memory SQLite doesn't work, wiring up a separate MySQL database, and what RefreshDatabase actually does in a browser test context. This one holds up. https://t.co/wloDnSwPKt
The reason you want MySQL for Dusk tests rather than SQLite: e2e tests are supposed to replicate what a real user would hit. Switching the database engine is changing the environment in a way that matters.
RefreshDatabase in a Dusk context runs migrations before each test and rolls them back after. Your testing database stays clean without you having to think about it.
phpunit.xml's in-memory SQLite config is great for unit and feature tests. Fast, isolated, no cleanup needed. Just don't assume it carries over to Dusk โ it can't.
The simplest Dusk database setup: duplicate your existing MySQL database name, append _testing. Point your .env.dusk.local at it. Done. Separate data, same engine, no surprises.
Dusk can't use an in-memory SQLite database. It's running in an actual browser โ the app has to serve real HTTP, which means a real, physical database on disk or in MySQL.
Do you bother matching your test database engine to production, or do you just use whatever's convenient? Genuinely split on whether it matters for most projects.
End-to-end tests should mirror real usage as closely as possible. Running Dusk against SQLite when your app uses MySQL in production is a subtle mismatch that can let things slip through.
This week we're looking at database setup for Laravel Dusk โ the parts that catch people out before they've written a single meaningful test. Episode drops Friday.