Laravel factories are a huge time-saver when writing tests. In the past, I’d build a factory to include every model property in the default state, but lately I’ve switched to having minimal factories by default. I’ll explain my reasons for this change, and what benefits I’ve found.

This is a really specific error you might never run into, but when you do, this blog post is here for you.

For me, one of the main reasons I write tests is to have confidence that my code is working as expected and to catch myself if (or should I say when?) I break something in the future. I often think of testing the happy path and the failure path, but I’ll share some additional things I like to test in between that further boost my test confidence.

Randomness can serve a useful purpose in factories, seeders, and tests. There are times it can cause issues though. Here are some rules I think about when introducing randomness into a test.

Why would you ever mark a test as todo? Isn’t that devaluing your tests? Not at all! I’ll share some ways I use todo tests effectively.

A couple days ago, I walked through a few potential gotchas with relationships in Laravel factories. Let’s see how it works in Laravel 8.

What’s the best way to define a relationship in your Laravel factories? I’ll share some tips that will help you avoid some common pitfalls, as well as give you a deeper insight into how factories work.

Let’s wrap up this series of tips, and show one final example when setting an explicit primary key value can improve the quality of your tests.

Yesterday I shared an example where setting explicit primary key values in your tests can make your tests more reliable. Let’s take a look at another example.

Based on the projects I’ve seen over the years, it’s a bit unusual to set an explicit primary key value when arranging the database state for a feature test. I’d like to share a few times when this strategy can make your tests more reliable.