Testing Inertia with Dusk
This episode is for members only

Sign up to access "Testing Inertia with Dusk" right now.

Get started
Already a member? Sign in to continue
Playing
12. Verifying database contents

Episodes

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

Transcript

00:00
So we probably didn't learn much in the last episode when we went through filling in a form, we've pretty much already seen that when we looked at testing our register flow. But let's take a look at a different scenario here. Now at the moment as this test stands we do not need to check
00:17
physically in the database to see if this task exists because we're redirected back to the task page which we already know lists from the database the tasks that we've created as a user. So as long as we see task 3 on the page it doesn't matter we've created this with the name here which we could even go ahead and assign a title just in case we wanted to go ahead and change that. We
00:40
could even say assert see in or whatever we wanted to do but we pretty much know that that task has been created now because we can see it on the page. Now what happens if we had a completely different flow to our create task page where when I went ahead and created out a task it didn't redirect us over to the task page maybe it just flashed a message to show us that the task had
01:04
been created. Now we could test and say well as long as we see a success message somewhere on the page we pretty much know that's been created but we might also want to dive into the database as well and see if that exists and this could be in any scenario but let's take a look at what this looks like now. So I'm going to go and go over to our task controller and instead of redirect back
01:28
to our task index I'm just going to redirect back. Now I'm going to comment these out because we want to kind of keep the history of the two flows that we have here. So I'm going to go ahead and redirect back to the last page but I'm going to say with and let's say some sort of status so let's say task created. Let's imagine that we're building an app where we can create something then
01:49
another thing and another thing we don't want to keep redirecting the user around. Okay so over on the create page let's pull this in so let's say just above our form we have a message here and let's say vif and we'll say status we'll bring that in as a prop in just a second and let's say status in here. Now this is very rough there are much better ways to do this but let's just
02:11
roll with this example. So we'll define our props in here our status is going to be a string and what we can do over in our controller here now is when we show the create page we can pass down the latest status. So let's grab that from our session so let's say session status and that should go ahead and display that on the page. Let's check it out in the browser first of all
02:36
so let's say task for task created so on and so forth. Let's just make that look a little bit better just while we're here and then we'll go ahead and look at the testing for this. So let's say margin bottom of 4 and we'll say font semi-bold okay yeah let's make this small as well text small there we go okay great so not great but you kind of get the idea. So now when we're
03:01
cranking out a task like that it says task created we would have to go back to our tasks page if we had a link to that to see that but now our test is obviously going to fail for a couple of reasons. So let's go over to our task store test and again we're going to get rid of this we'll just comment it out and we'll create a new one just up here so let's go ahead and get rid of this one and
03:25
let's change around this test for this specific scenario. Obviously it's going to fail if we run this now because it's going to wait for that task location which isn't going to be the case anymore and after like five seconds or whatever it's going to fail and yeah we obviously don't have this flow anymore. So what do we do in this scenario? Well we're going to go ahead and press
03:47
the create task button. What's going to happen? Well we could assert that we see some text so let's say task created now we're getting into the brittle test stage unless we're using language files where we would want to see this but obviously if the text changed it would fail our test. Let's run this anyway despite that and see what happens so it creates a task and it still failed
04:13
why is that? Well let's go up and have a look so it can't see task created it can't see that text anywhere. Once again this is an issue with waiting for things so again what we would need to do because it's not instant and we are within a browser environment we want to wait for that text so we want to wait for the task created text. Now we could then assert it but this is pretty much
04:40
already an assertion on its own so this is not really needed. Let's go ahead and run that test again now that we've added that wait which again is probably one of the most important parts of writing end-to-end tests waiting for things before you assert and you can see sure enough we get green. Okay so that is the different flow with the waiting for stuff but how do we verify
05:03
that this is actually in the database? Of course if we were to come over to our task controller and get rid of this line which is arguably the most important part of this the test is still going to pass so we are really just asserting here within our test that we can see a flash message which is not really the most important thing. So what we want to do is as well as our browser
05:25
functionality we can also dive in and use any of the regular methods that we would use to check that the database contains a value. Remember we're working with the database within our app through the browser that we would normally do if we were manually browsing. So what we can do here even outside of this browse because we don't really need to do that within here we can go ahead and
05:48
assert that the database has something within the tasks table given what we've created. Now the only issue with this is that we've specified the title here as a variable so we can't really reuse that in here unless we assign this up here somewhere but let's go ahead and fill this in and then we can always fiddle around with it. So we're going to assert that the database has within the tasks
06:10
table a task called task three so now even though we're not going back to the previous page to visually see that it's on the page we can add an assertion in here to make sure that it actually exists within the database and this can be really useful in a number of scenarios where you're doing stuff people are clicking stuff there's not really much happening but you want to check behind the
06:32
scenes to see if this is actually taking place. So there's nothing stopping you from taking this assertion just here and putting it directly inside of the browse part of this it's still going to work in exactly the same way and if you were to do that you can then of course use the title that we assigned at the top there it doesn't really matter where you put this in the journey it's
06:55
still going to work. So the key point here is that although we're creating browser tests and we are wanting to look on the page to see if things are actually there we can also couple this with any of the other testing features that we have and we can also use things like expect within pairs like we've seen before within our tests as well and there's nothing stopping us from doing this if it
07:17
makes our test a little bit more solid and of course if we head over to here and get rid of the line that was the most important we know that our test is now going to go ahead and fail. Great okay let's bring that back and that is pretty much how we go ahead and write a slightly different test depending on the flow checking things like the database.

Episode summary

In this episode, we shake things up a bit and look at how to properly verify that something we've created (like a task) actually exists in the database—not just on the page. First, we go over why, in a typical redirect flow (like after creating a task), seeing the new task listed is usually enough to confirm it’s there since the list is generated from the database.

But what if our app doesn't redirect us to that listing page after creating a task? Maybe it just shows a quick success message. We show how relying on just that message can make our tests brittle—especially if the wording ever changes. So, we tweak our test to also check directly in the database to make sure the task was actually saved.

We demo how to assert database contents in your test code, discuss where to place these assertions (inside or outside the browser flow), and explain why it's important for robust testing. By the end, you'll see not just how to verify UI feedback, but how to confidently confirm that the data is really there behind the scenes too.

Episode discussion

No comments, yet. Be the first!