Up And Running with Pest
Playing
12. Creating a book

Episodes

0%
Your progress
  • Total: 4h 19m
  • Played: 0m
  • Remaining: 4h 19m
Join or sign in to track your progress

Transcript

00:00
Now that we have tested our authentication and we've looked at some PEST-specific functionality, we should just be able to dive in and start to test something a bit more interesting, and that is going to be creating or storing a book. We're not going to be testing the form, we're going to be building and testing the functionality that's actually going to store
00:17
a book for a user, and then later we will go in and build the form. So let's just close everything off here and let's create our new test and just start writing our tests before we do anything at all. So let's go ahead and make a test in here. What I tend to do is call these book and then what's happening, and then of course at the end in the suffix we use test,
00:37
and of course we want that to be a PEST test. So over in book store test, let's think about the first thing that we want for this store endpoint. Well, the first thing that comes to mind is we need to be signed in. So let's say only allows authenticated users to post, and we could make this as a higher order test. So let's get rid of this function here,
01:00
and let's come down and post through to that endpoint, which we haven't built at the moment, but that's going to be slash books, and then we're just going to say assert status 302. Okay, so that's going to be a redirect. We could add that we're redirected, or we could use one of our helpers that we built earlier, but this is slightly different. We need to be authenticated
01:21
rather than be a guest. So we'll refactor this later to make this a little bit clearer rather than having some sort of status. Okay, so let's go and just run our test and just see what we get. We'll specifically run this test. So tests feature and bookstore test, and of course we get a 404 because we haven't built this out yet. So that's the first job to do. Go ahead and build this out.
01:43
Let's go make a controller. That's going to be book store controller, and let's go over to our roots and just register this. Let's pull one of these down. Remember, this is posting through to store a book, so that's going to be storing through to books, and we have book store controller. Great. So let's go ahead and run our test again,
02:04
and this time if we just come up, we get an error because we haven't added anything that invokes this. So let's go ahead and add our invoke magic method into here, and let's just do nothing, and let's run our test again, and we get a 200. So obviously this is failing because we need to be authenticated or we should
02:26
be authenticated redirected. If we're not authenticated, we're not in this case because we don't have any middleware. So let's define this out within the controller, and we need to be signed in. So we'll just use the standard auth middleware. Run that again, and we get green. So we know now to access this, we need to be authenticated.
02:45
Now we can write a more interesting test if we just head over to our test here, and that's going to be that it stores a book, and we can figure out what kind of data we want to pass down at this point, and then we can implement it in the back end. So let's say it creates a book. That kind of makes sense. We'll make this closure based because to make this higher order based is not
03:04
going to look that good, and we want to go ahead and act as a user. So let's say acting as. Let's go ahead and create a user. So user factory and create, and we want to post through to slash books, and the data that we want to post through is the title, the author, and of course, the status as well that we saw a little bit earlier from the introduction. So let's say title
03:28
a book. Let's pull this down, and author is going to be an author, and then we want a status in here. Now this status is going to come from a pre-filled drop down, so it's going to look something like this. Want underscore, to underscore, and read. So we'll implement that later. Now what we want to do is implement this with a pivot table. The reason being is if we create a book, so book one, book one
03:58
might be just a book on its own, not attached to a user with no status, but then the pivot table for this will link the user to this book, and that means that later on if we want to, we can reuse books. So rather than each user creating every single book and duplicating books, we might want to store them in one central place and just link them with a pivot table. So that's what we're
04:20
looking for. We're looking for the book existing within the books table, and the pivot existing, or the status existing with a pivot inside of some sort of book user table. So let's go ahead and create a checkout for this. So assert database has, the first one is pretty straightforward, that's just in books. So we want to make sure that in the books table we have all this information.
04:44
So just these two pieces of information here, and then we also want to assert that in say book underscore user, we have the user's id. So in actual fact let's go and pull this up here and we'll be shifting this around a little bit when we look at our hooks within our tests. So user, and let's say user id, user id, and then the status should be want to read, like so. So that
05:20
should then prove to us that this is linked up to a user. We can actually chain this, so why don't we chain this down here, like that, great. Okay, so let's run this test. Obviously this is going to completely fail, and let's have a look why, because there is no table users at the moment. That's not the reason it does fail though. So let's head over to one of our other controllers,
05:40
or one of our other tests, and let's just grab our refresh database tray. We'll pull all this in actually. So let's come over to this test and let's get rid of these two for now. Let's run this, and okay, so what is happening? We don't have a books table. That's what we need to do first. So let's go ahead and create our model for this. So make model and book migration
06:07
and factory for this, of course because we're testing a factory is going to be really helpful. So let's first of all fill in the migration for the books. Let's go down, very very simple, we just want a title and an author. So let's add both of these in here, author, and that should be enough for now. So let's go ahead and run phpr to migrate, and that's done. So now our test is
06:30
going to be slightly more complete. So if we just go over to run this test again, the problem now is that we don't have this in the database table. So now what we can do is start to hook up the relationship between the user. So let's go down to here and say that a user has many books, but this is not going to be attached directly to the books. We need a pivot table. So we've got the
06:52
relationship in there, but we don't know how to implement this just yet. So let's go ahead and create out the pivot table. So let's make a migration, create book user, book being first just because it's in alphabetical order, table, and let's go and open that up, create book user table. So for this, we're just going to link up a book with a foreign ID, so book ID,
07:18
and we'll constrain that to a user. So let's say user ID. There we go. Let's run phpr to migrate, and we're done. So now we can hook the relationship up, and we should see that information in the database once we hook everything up. In fact, we could make this test half pass by just creating the book and then going ahead and hooking it up later.
07:42
So why don't we make half of this pass first of all before we implement that relationship. So we're just going to say book create, really, really simple, and we need to get this information from the request. So let's do that now, and we'll just say request only title and author, done, and let's put our request object in here, not from Guzzle, from Illuminate and HTTP.
08:07
Let's just rename this real quick, and rename that to just the normal request. Great. And that should be enough. So that should be enough to pass half of it. Let's rerun our test again, and if we just come up here, we've got books, matches. Ah, so it looks like this isn't actually creating the book. That might be because over in our book model, we don't have our fillable
08:31
properties in here. So let's add that in, and that's going to be title and author. Let's run that test again, and we should get something different now. So it's still not in there. So let's figure out why that is, and that is because I've implemented the creation of the book inside of the books relationship within the user model. You probably noticed that.
08:55
That is why we test. So let's go over to our bookstore controller, and actually do this in here, and put our request into here, and we should be good. Let's wake up. There we go. So this should now half pass, and it does. So the only issue now is we're not linking this to a user. The book's being created. It's just not being linked to the user. So that is where we
09:20
actually now want to come over to the user relationship, and we want to go ahead and implement the books relationship here. So this is just a belongs to many relationship. So we're going to say belongs to many and book, and we're going to need to come back to this in a minute for the pivot status, but let's go over to our bookstore controller and actually attach this to
09:40
the user. So we're going to use the currently authenticated user just from the request. Access the books relationship and attach that book, and once we've attached that book, we want to pass in some additional pivot information, which is the status of the book. So we can just pass this in from request and status. So that should be enough on its own to fill that book
09:59
user table with the data that we're expecting. If we run our test though, you can see that this doesn't quite work. We've got the user ID in there, or we should have the user ID in there, but the status is not going to be in there. So I don't know what's going on with our test, but let's just open up this and get rid of and want to read because that's not going to work.
10:21
Let's just rerun our test again. You can see it's not quite worked. So the reason for this is we don't have, if we just come over to our bookstore controller or our user model, we don't have the pivot information on here. So let's say with pivot and status, and let's also add with timestamps as well. So we get them filled for us. So let's run our test now and it still doesn't work. So let's
10:46
go back over to our bookstore controller and see what we are doing here. So let's just have a look. It doesn't look like that is being inserted. I actually have a feeling that we forgot to include the status and we did. Let's go ahead and add that in here now. And let's just roll back our migrations. So php artisan migrate rollback and let's
11:08
rerun our migrations just to make sure that's in there. Okay. And there, there it is. So let's try and rerun that test and we get green. Great. So it was just that we'd forgotten the column classic. So after we've done that, we want to go ahead and redirect the user back to maybe just the homepage for now. And that is now storing a book alongside a status. Now we can't forget to test
11:33
some validation because of course we require the title. We require the author and we require the status as well. So let's just create out a test down here just to validate that information. Of course, we haven't implemented validation just yet. So let's say it requires a book title, author and status. And let's do this as a higher order test. I think that would make sense.
12:01
So let's go and just tap into here because we're going to need to act as that user. Let's create a short closure in here. Let's say this acting as now we want to reuse probably the same user to make this a little bit easier. Let's look at a pet pest specific syntax to run something before each test. Normally within PHP unit in a standard test, you would implement some sort of setup
12:26
function or something like that. What we're going to do though is take this user and we're going to say before each and we can run something in here before each test. And what we can actually do is we can say this user. So let's change this to this user. And now the user property is going to be available in every single one of our tests. So this really helps just so you don't have to
12:51
scaffold this up in every single test. So we can just say this user in here. And then now we don't need to create that user in here. We can just reference that user again. And that makes our higher order test a little bit cleaner as well. So we're going to go ahead and post through to slash books. And we're just going to assert that the session has errors. And that's going to be
13:14
title, author, and status. So we're not specifically validating the status just yet. We will be soon just making sure these are required. Now I'm going to go ahead and get rid of this test just for now, just so we can make sure what we've done here, for example, here, I haven't referenced this user ID is working. Now a really good way of doing this
13:34
within pest normally what we would do is we would comment this out a little bit inconvenient. What we can actually do is use a skip method within pest. This is really handy. So we don't have to comment things out, delete them, move them somewhere else if we just want to skip those tests. So let's skip that test and rerun this. And yeah, we've got a failure session is missing
13:55
expected key errors. And that is not actually skipping that. So let's figure out why. Let's maybe put this here. And let's finish this off here. And let's just rerun this test. And there we go. So that test was skipped. The reason that didn't work is because we're trying to call skip on the response that we get back. So if you had a closure based like this, rather than a higher
14:19
order test, you'd want the skip at the end here. So you might want to skip that test. Otherwise, you'd want it directly on here. So we've just looked at basically skipping test really handy. So we don't have to keep commenting things out. OK, so we know that they're now working out. We switched to that before each. Let's run this again. And of course, it's saying session is
14:38
missing the expected errors because we don't have any validation inside of here. So let's validate this just directly within the controller. And then once we've got a passing test, we could potentially move this over to a form request. So let's go ahead and validate our request. The title here, we're just going to say is required. We're going to keep this validation
14:54
really basic for now. The author is required. And the status is required. Of course, we're going to want to validate that the status exists as the status is that we want. We don't just want any status put in there. So that should be enough to make that test pass, which it does. And then we can start to add more validation rules in here as well. So in the next part, what we're going to
15:17
do is just add another test, which is going to validate the status here. We're going to set this up in a way that we can reuse the statuses across our app using a custom class for our pivot. And then we'll come back to this and just make sure that we're validating that the status that we pass through is an acceptable status.

Episode summary

In this episode, we dive into building the feature that lets users create (or store) a book in the application––moving on from our earlier authentication and basic Pest testing setup. Instead of starting with the form, we focus directly on setting up and testing the backend logic.

First, we plan out our test for the book creation endpoint, thinking about authentication and ensuring only signed-in users can create books. Then, we scaffold a new controller and set up the relevant routes. After wiring up some basic logic to get the authentication working properly, we move on to structuring our database: setting up the books table (with title and author fields) and the crucial pivot table book_user to link users to books with an extra status field for things like "want to read", etc.

We also set up and implement model relationships to handle this many-to-many linkage, making sure that storing a new book also stores the correct data in both the books table and the book_user pivot table, including the status. Along the way, we troubleshoot common stumbling blocks (like remembering to set fillable properties and adding the necessary pivot data).

Testing plays a huge part throughout. We build out Pest tests to check both the database records and validation rules (making sure required fields like title, author, and status are enforced). We also talk about handy Pest features like skip for temporarily ignoring tests, and how to DRY up our tests using before-each hooks for shared setup.

By the end of this episode, we've got a fully working backend for creating and tying books to users with statuses, and solid tests to prove it. Next time, we'll look at polishing our status validation, making sure only expected statuses are accepted using a custom class. It’s hands-on and full of practical testing and Laravel relationship tips!

Episode discussion

No comments, yet. Be the first!