Laravel Lazy Database Refreshing

so here's a small but very cool new feature in the latest version of layervl8 the framework can now lazily refresh your database when you're performing your tests let me show you an example here i have an older install of laravel and if i go to the abstract test case this is what you get so notice there's no reference to refreshing the database instead because it would run for every single test it wouldn't make sense to put it here if i visit a feature and if this imaginary feature would touch the database i would add it here so use refresh database and you've probably added that countless times okay well now in the latest version of laravel and i'm going to switch to a brand new project three two one here's example latest well now you'll see on test case it automatically uses this lazily refresh database trait and again it does what it says on the 10 it will only refresh the database if you touch the database hence the word lazy and if you want to take a quick look at this behind the scenes it's still going to defer to refresh database but it will only do that if we touch the database so before executing this is sort of like a hook that will be fired right before we touch a database so only when we do that do we actually refresh the database it's kind of cool okay so because this is not being performed lazily it does make sense to put it on your test case which means all of your feature tests no longer have to manually pull in refresh database or lazily refresh database you can instead keep it on that abstract parent okay so to demonstrate this i've set up a simple little typical post test i have two tests here which handle the setting of a slug one of them will not touch the database and the other will all right so let's say if i had a post where i give it a title of some title then we're going to be fairly naive here but the slug should be some dash title so i could say this assert equals some title post slug i stay naive because of course what if you have thousands of posts and some of them have the exact same title well in that case you would have a clash with your slug and you would need to append some kind of random string or an incrementing number to the end of it but this will get us started so we give it a run and of course it fails but now before i even make this work think about how it used to be if i were to go to test case and bring this back to the standard refresh database and we used that well that would mean we're going to refresh the database for this test even though we don't need to so to illustrate this why don't we go into the trait we're refreshing my test database and yeah maybe right here just for a visual we'll say migrating the db so yeah now if i give the test a run sure enough i'm migrating my database even though it serves no purpose so i'm paying a performance penalty for no benefit okay but now if i undo this and i bring it back to lazily refresh database if i give it a run again we do not migrate the database okay very cool let's go back to post test and we're going to make this work maybe of course we can do this in a number of ways but why don't we use a simple mutator so maybe when you set the title well yes we need to set the attributes so title is title but then maybe we'll also set the slug and again this is going to be fairly naive to start string slug title and this should get us going so if i give it a run it passes and we did not touch the database cool so let's go back to my post test and we'll do another one it ensures that the slug is always unique so yeah what if i have multiple posts with the exact same title well right now our logic would create the exact same slug which is not allowed that column needs to be unique so what if i said here how about post factory create and i'm going to hard code the title the sum title so this is our given given we already have a post in the database with this title and presumably with this slug well if we want to be redundant i could have an assertion here and that's going to once we store that in a variable that's going to pass we already know that but yeah if we were to do it again like this well now we would expect something else so some people will create a random string some people will append a timestamp or some will simply increment an id so maybe if we already have one we'll start at two and then if you create another one it would go to three that's fairly common too so how about our test does something like this just to prove that we increment it each time we add a new post okay we give this a run and now of course it does fail we expected that but i want to point your attention right here we touched the database so only on that condition did we migrate it okay now let's make a pass right now we get an integrity constraint because we're trying to set the slug equal to something that already exists in the database okay how do we want to do this if we keep this in line our first step might be something like well generate a slug and then look in the database to see if there's a post that already has that slug so we might say while we can find a post that has this slug and we'll say if that exists well then we need to change the slug so for example maybe we would do it again but this time we will append a dash and then maybe some kind of incrementing index okay and maybe we'll start at two there and of course increments okay so i think that should probably do the trick it's kind of quick and dirty but let's go over this when you set the title we're also going to set the slug because the slug is based on the title so we try to sluggify it and then we look in the post table and we check is there some kind of post that already has that slug if one exists then we need to change the slug and we're going to allow for that by using an incrementing index so let's change it now to something like sum title dash 2 and then it's going to run again could we find a post with that slug if so then it's going to be this then this and only until we can't find a post do we continue forward where we set the slug okay so if i give our tests a run it does pass okay so i think if i run everything that should do the trick and you get the general idea so now at this point you might want to i had some kind of make slug and that would allow you to do something like this this makes slug where you take all of that and you put it in here for the title might be useful to pass that in as a param but i'll just grab that off of the object and we get something like this and let's see oh yeah we do want to return a string so we'll return slug all right yeah that passes anyways we're getting beside the point of the video the main thing to understand is all new installs of laravel will include this lazily refresh database trait on your parent test case which means you no longer have to manually add refresh database to every single feature test you create now if you're not creating a fresh fl project of course you still will have access to this trait you can just add it manually to your parent class and then visit all your feature tests and be sure to remove any lingering refresh database traits that you imported there you don't need to do it so remove it from each feature test and let it live on the parent

Channel: Laracasts

Views: 1,005

Keywords: web development, php, programming, laravel, laracasts, jeffrey way, coding

Id: RTVhZamCXHw

Length: 8min 9sec (489 seconds)

Published: Thu Oct 07 2021