Codecourse

The most practical screencasts for developers

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

New Episode today. https://t.co/mPYXh2JVyz

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

Two new columns on the server_tasks table: title and description. Simple migration, but it unlocks dynamic job labelling across your entire queue pipeline.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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

[Codecourse @teamcodecourse]

What's the part of your test setup you'd most want to go back and fix? Infrastructure, naming, structure — most projects have something.

[Codecourse @teamcodecourse]

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

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

At what point did you start taking test isolation seriously? For a lot of people it's after losing local data during a test run rather than before.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

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.

[Codecourse @teamcodecourse]

New episode on Codecourse this week: Blade and view data — part of Getting Started with Laravel. https://t.co/mkbmoHVyYY

[Codecourse @teamcodecourse]

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.