9 hours 41 minutes
Hi. Welcome back to module for this is less than 4.7 layer volt. Tinker for testing. Now, what is level? Tinker? It is a python program and it's used to test Larible models
in this lesson. We're gonna test our models. We're gonna test the relationship to ensure that we have them set up correctly. Now, when we tested these relationships is going to return an array of objects that fulfill the relationship
and an array in any programming language is just a collection of models or objects.
Now Larible is running queries behind the scenes when we implement these relationships. So when we take a model and we ask for all of the related models,
what level does behind the scenes is actually builds the query
that would create that relationship and then executes it and then returns you the results in other models that it again builds
for you. Now, if you weren't using a framework, there'd be a lot more work entailed in this. You would have to,
uh, embed queries and create a way for your objects to create those queries.
But with level and tinker, we will be able to test our models pretty easily with very minimal amount of code.
I will come back. Let's go ahead and get started. So I'm gonna open a shell session into my Bagram box. So fragment Ssh!
And then we need to go ahead and go into our shared APP
directory and go to our first file. We're gonna move file by file, testing the relationships, making sure that they all work.
Once we have that shell session open, we want to see the into our root directory of where these all those APP files are.
And then we don't want to run the command. PHP are Titian, Tinker,
and that's gonna open the Tinker program
and we will start running commands. So the first thing we're gonna run his building Colon, Colon, find one. So that's gonna find the building with I d one.
So that is not saying, find one or anyone. It's fine, specifically the building with I d one.
So that returns the test result I had type in.
Now the cool thing here is you can go further and let's say Okay, once I have building one, I want to know the name of that. For some reason, I could just do this
and further break it down.
So we want to test the relationship, which is rooms
and the rooms. Definition is right here. Pretty short, pretty sweet. So rooms and that is related to this building has many
so we'll run that. I get the rooms back
now. The difference here is that I'm getting a collection or an array, so they're just happens to be only one room
so again and Ray with just one room in it.
So if I try to, for example, just go straight to the
name of the room, I can't get in air.
But if I do this number, I say first
and then I say name,
then I would get Thea the name.
It doesn't even mind.
We're not going too far into this or just doing enough so that we can easily see the database so that when we create a model, we can go and then say, OK, give me the rooms of this model and put in this test data.
Okay, so that completes the building.
Let's go ahead and open the course.
So again we're gonna do is typing course. Colin Colin to find one.
Okay, we got a room back. So that's working
All right, so those are the grays that are entered for that course.
So that's working. Let's go to the next one, raid.
So again, I'm gonna do grade. Colin. Colin, find one.
All right, let's test the grade relationships. What user does this? Does this great belong to
that user? Okay,
Yep, that's all looking good.
Move on to the next one, Which is the room. So room
corn, find one.
This is the one who gave me an idea of two and not one.
So there we go.
So arrow courses.
on, then building. What building does the room belong to?
that's working. Next we go into the user file
again. User going corn, Find one.
All right. That's the user one. Yep. On let's get his grades.
There are his grades and user courses.
See if that works
and let's go into the next one.
So this will be
use, of course. So, user course.
All right. And then let's find his user.
Let's find his course
that worked. And let's find his
and we got no back. That doesn't appear to be correct.
Let's go and take a look at what we have going on in user type
Right? It's going to the migration file
Go into the
Okay, so here is the The problem is I put type underscore. I d
I should have put user underscore type I d.
When we go in and change that
and then I will need to change. This is Well,
the reason that didn't work is because levels making assumptions on how I named things. And if I accidentally deviate from what level expects than the framework
makes the wrong assumption. And I don't get the right answer back.
So now with that change, when exit,
I'm going to a PHP partition.
My great fresh.
Actually, we need exit. Uh,
now that'll work. PHP are Titian,
my great fresh.
Okay, so I need to change this unique key.
Run the migration again.
Okay, I'm back. After running that migration, I had to go back and insert some dummy data because as we know, the migration rebuilds everything. So I lost all my test at that is part. The reason we're going with the database seating is because once we have the seeding process set up,
if we re migrate, it won't matter. It will. It will receive the database for us.
So let's go ahead and go into tinker again
on we were typing
gotta capitalize. The u
see what we got here. I hope I didn't say that.
Here we go.
Bring back open my shell and it looks like I have an idea of three.
my relationships were
I see, user
and use your type.
And last but not least course.
we go back into that folder and see that was the last one we had in the APP folder. Of course, user type was the last one was going and open that
then user type colon colon. Find one,
all right. And he has a user course relationship used, of course,
and that's working.
So all of our relationships are working. There was one problem in which I accidentally left out the user out of the type. I had a column that was called Type I D or type underscore. I d to be specific and it should been called user underscore type underscore i D. And that is because when we were setting up these relationships,
Laurel is assuming that based on the model name and the table name that certain Colin names
specifically associated with the i d are going and have a specific name based on the table in the model and when they do not,
um, you can either tell level that you've used another name
or levels not gonna create the correct relationship or is gonna look
create a query that won't get the results you're looking for.
So let's go ahead and head over to the summary,
and that brings us to less than 4.7 layer. Vel tinkers Summary. What do we do with this lesson? We use Larible Tinker to test our model relationships. We discussed why and when to use Tinker again. Tinker is used to test the models and the relationships that you've set up in a terrible application,
and we would just want to verify that they're working so that when we go to set up our
database seeding process will be confident that that process will function correctly because to add a bunch of test records to our database will be will have to be certain that the relationships are working correctly so that we can very quickly generate a bunch of fake data. Now, with that said,
let's see the database in the next couple of lessons
hope to see you there. Thank you.
The Microsoft Azure Test is a premium Cybrary assessment created by iMocha. The exam will ...
AWS Data Engineering
The AWS Data Engineering test is a premium Cybrary assessment test created by Interview Mocha. ...