Now, you've learned a bit about class-based model factories, so let's move on to relationships and how we can work with those. Let's set up a simple relationship. A User can create Posts. Give me a Post model and include a migration and factory. So there's our factory and, of course, our migration. So if I were to do this quickly, let's set up our foreign ID. A Post belongs to a User. It has a title, a body, all of that stuff. We'll just keep it super simple.

It has a title, a body, all of that stuff. We'll just keep it super simple. So there's your migration. Next, your PostFactory can define this, like so. And don't forget, we can always access the faker dependency directly on a factory instance. So that'll be a sentence. But what about the userId? How do I define that? Very simply. If we have our User, give it a factory.

Very simply. If we have our User, give it a factory. And behind the scenes, Laravel will take care of that. Okay, so now, let's go ahead and migrate our database. Good. Okay, so what if I wanted to say, for a test, given I have a User with five Posts, how would we allow for that? Okay, let's take a look. php artisan tinker. And let's start by pulling in the User and Post models.

php artisan tinker. And let's start by pulling in the User and Post models. So I could say userFactory create, and yes, that'll persist a single User, but it doesn't include the posts. So what you can do is reference this has method. So a User who has five posts, postFactory count five. And this should work, ideally, but it's going to fail. Call the undefined method User::post. And actually, that should probably be plural. So what's happening here is Laravel assumes you have the proper relationship set up.

And actually, that should probably be plural. So what's happening here is Laravel assumes you have the proper relationship set up. So right here, if a User has many Posts, we need to define that. Return this hasMany Post. Okay, so now, if we were to try again, let's import those models and call that method. Now it's going to work. Let's have a look. Here is our second User. And then on the Post table, we have five Posts associated with that User. That's great.

And then on the post table, we have five Post instances associated with that User. That's great. However, let's clear this out. We can even simplify this a little bit more. This clearly is a bit verbose. So instead, we can use a magic method like hasPosts. Run it again. And now we have a User with an ID of three. And if all went according to plan, we should now have five Post instances written by the User with an ID of three.

And if all went according to plan, we should now have five Post written by the User with an ID of three. So that ends up being quite a bit cleaner. Now what if we wanted to do this in reverse? We wanted to say, well, I want a Post for the given User. And maybe, in fact, we want three Post for that given User. All right. Well, I can say four. So four would be the inverse of the has method. Inverse would be for some many-to-many relationships or hasMany.

So four would be the inverse of the has method. Inverse would be for some many-to-many relationships or hasMany. Four would be for a belongsTo relationship, which makes sense. Give me a PostFactory for a User. And if we run this, it's still going to fail. We don't have the relationship defined. So we visit Post, add our User, and that relationship is a belongsTo. A Post belongs to a User. Okay. So one more time.

Okay. So one more time. Oh, I'm sorry. We have to exit out. Give it another try. Use those classes and run it again. There we go. We now have three Posts, each of which belongs to the User with an ID of 4. Now in the same way, I could just say for User. And now we get the same thing.

Now in the same way, I could just say for User. And now we get the same thing. Notice that the userId is the same. So if we did not have that, this would create three Posts, but each of those Posts would belong to a new User. That was scaffolded.