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
15. Dealing with race conditions

Episodes

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

Transcript

00:00
Let's talk about race conditions. I'm going to show you an example of how we can write an assertion within our test but the assertion can actually beat the action taken within our app and we're going to see a visual example of this when we write a test
00:16
and we think it passes but it's actually going to fail in reality. Okay so this is about cancelling the deletion of a task but this can apply absolutely anywhere. So let's say it can cancel deleting a task and we can pretty much reuse
00:33
more or less everything we've got here so let's go ahead and just grab everything from here paste it in but for this we only need one task so let's get rid of times here and we'll get rid of the task from there and let's just visit this page and press the delete
00:49
button for now and let's take a look at this and yeah I think that looks good. So let's go ahead and run this in isolation make sure that's working and then we'll start to add our assertions. So can cancel deleting a task and that passes with zero assertions.
01:04
Okay so what do we want to do here? Well rather than accept the dialogue which we've seen here we can go ahead and dismiss a dialogue so that will go ahead and press the cancel button that we see over on our tasks page here
01:17
so that will press that button and obviously we just want to make sure that the database still has that task in it shouldn't have been deleted. Sounds pretty straightforward right? Well let's go ahead and say assert database has
01:30
tasks and let's go ahead and pass the id of the task in so task id and let's go ahead and run our test and check this out. Okay yeah great it passes and we know that by cancelling this it should still work. Let's now go over to our task item where we're going
01:52
ahead and returning here doing an early return if we cancel this dialogue and I'm going to go ahead and comment this early return out so now what is going to happen in our actual app if I go ahead and delete
02:05
something and hit cancel it's going to fall through and actually delete that task which obviously is a bug but let's go ahead and run our test and see what happens. Okay so we're in trouble now because our test is showing that this is successful
02:20
but obviously this will have actually been deleted in the database so what is happening here well kind of like what we've done elsewhere so just here when we had to add this wait until missing text what's happened is we've dismissed the dialogue but then instantly this test is
02:37
checking if the database has this task. Now there are some circumstances where this test might pass or it might fail but what we're not doing is we're not waiting for the next request before we go ahead and start to assert now there's nothing we can
02:53
really test for over here when I hit cancel so if I click delete and cancel nothing on this page changes obviously deletes but within our test it doesn't so how can we do this well a tip or a trick that I use when I'm working with inertia to make sure that the request or
03:11
the page has kind of been refreshed we know that in inertia pages don't refresh but they do update we can go ahead and say wait for location now what this will do is it will wait until the next request it will wait until that request has been made
03:27
and we're sort of redirected back to this page so we can say well let's wait until we're redirected back to the tasks index which will effectively mean that this has been updated and we're basically detecting an inertia refresher data
03:43
so let's go ahead and run our test again with that early return cancelled out and yeah great we get a failure which is what we expect so we can now go ahead and just bring back that early return run our test again and sure enough that should pass
03:58
so these are the really tricky parts of writing end-to-end tests making sure that you wait for things to happen for tests like we wrote earlier when we waited until this text was missing that's pretty obvious but if nothing should change on the page if we hit cancel or dismiss a dialogue then the
04:15
next best thing is this which is really key waiting for a location we're basically just using this here to wait for an inertia refresh now there are other ways that you can get around this like using pause but i tend to find these not as
04:29
reliable using wait for location means that we know that we've been redirected back and then we can safely assert once that has happened that something has physically happened behind the scenes
22 episodes•2 hrs 53 mins

Overview

How do you test real flows through your Inertia applications? With end-to-end tests!

In this course, we’ll cover everything you need to know about setting up, writing and running browser-based tests. Once we’re done, we’ll configure CI (Continuous Integration) with GitHub Actions, to run your tests whenever you push new code.

Don’t use Inertia? No worries — there’s plenty to learn about end-to-end tests with Dusk in here too.

Alex Garrett-Smith
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!

Episode discussion

No comments, yet. Be the first!