در حال بارگذاری ...

Testing Context Dependencies0:00

So, the context is a fantastic feature, and you might be thinking that, hey, I want to use this in my applications, and I highly encourage you to do so, because it is a fantastic feature. But you also might be thinking, well, how do I test with the context? If I start using that throughout the application, how am I going to test the different parts of the application that uses the context? And if you think about it, the context is really just a dependency injection container. It is a container that you are injecting dependencies into, and then you can use those dependencies wherever you need. So the answer is really very simple, just like anything else.

wherever you need. So the answer is really very simple, just like anything else. So let's look at how we can test with the context. We're not going to spend a whole lot of time, because the overall concept is really nothing new here. We're just applying it inside of the context of testing. So let's say that we will have a test for the dashboard displays the account name. And so that means we will need to make a GET request for the dashboard. And let's assert two things. First of all, we want to be sure that we get an OK response.

And let's assert two things. First of all, we want to be sure that we get an OK response. We don't want a 500 or not found. That would not be good. We want an OK. And then we want to assert that we see the name of our account. And let's just say that we'll have an account called Foo's Guitars. So that would be our test. We just need to set this up. And if we are going to start using the context throughout our application, then it almost

Writing Dashboard Test Setup1:31

We just need to set this up. And if we are going to start using the context throughout our application, then it almost makes sense to just set up the context before each of our tests. So that's what I'm going to do. Before each, we're going to create a User. And the User information doesn't really matter. So we're just going to use the factory to create a User. And that's going to be that. But then we need an Account. And you know, like the User, we really don't care except for the name.

But then we need an account. And you know, like the user, we really don't care except for the name. So whenever we create that account, we'll just say that the name is going to be Foo's Guitars. And that's going to be fine. But we will need to add that account to the user's account. So we will save that. Then in order to see the account information in the dashboard, we need to essentially access the dashboard as this user. So we will call actingAs, and we will pass in the user that we plan to use to access.

Diagnosing Test Failure2:24

the dashboard as this User. So we will call acting as, and we will pass in the User that we plan to use to access the dashboard. We do need a use statement for our User model. But other than that, you know, ideally it would work. It's not going to work. And it's because we don't have the account in the context. So if we scroll up, we see that the response is a 500. So we failed that first assert, which means we obviously failed the second assert. So let's look at the log because that's really going to tell us what exactly went wrong here.

So we failed that first assert, which means we obviously failed the second assert. So let's look at the log because that's really going to tell us what exactly went wrong here. So we can see that we attempted to read the property of name on null. And it doesn't really go into any detail except that it's in the dashboard view. But really what's going to be telling, and of course it gives us the line number, that's kind of important. But the most telling thing is going to be at the very bottom, you know, because all of our context information, at least as far as the user and the activeAccount, is in the context. It's not hidden.

the context. It's not hidden. So it would be written to the log, even in the case of our test. So we can see at the very bottom, we have that context information. And right off the bat, we can see that activeAccount is null. So then the question becomes, why is it null? Because we have the User, obviously. So if we take a look at our middleware to add things to the context, well, we add the User by the auth facade, but then we see the activeAccount. We're loading that from the session.

Middleware Overwrites Context3:55

user by the Auth facade, but then we see the active account. We're loading that from the session. So duh, I forgot to do that. So that's easy enough to fix. We can go back to our beforeEach. What if we use the context here, and we add the active account, and we set that to our account? Now, this is perfectly fine. We can do this here, but this isn't going to fix our particular problem. And it's because we are loading that context data inside of the middleware.

We can do this here, but this isn't going to fix our particular problem. And it's because we are loading that context data inside of the middleware. So even though we are setting up the context here, we are still going to be loading the context inside of our addContext middleware. So this code is still going to execute. It's going to set null for the active account in the context. And so therefore, it's going to fail. So I knew that beforehand, but I wanted to at least point out that yes, even though we are inside of a test, we can still set contextual data inside of our tests. It's just that in this case, it wasn't going to work because we essentially overwrite whatever

Fixing with Session Data4:52

are inside of a test, we can still set contextual data inside of our tests. It's just that in this case, it wasn't going to work because we essentially overwrite whatever is in the context inside of our middleware. So that's easy enough to fix. Since we are loading data from the session, we just need to add our accounts to the session. So we will call withSession. We will provide the activeAccount session variable set to the account that we have created. So that is going to fix our particular problem. Whenever we run the test, we will see that it passes. And hooray, our code works.

Planning More Flexible Setup5:25

Whenever we run the test, we will see that it passes. And hooray, our code works. But what if we wanted a little more flexibility so that we could provide our account through the context inside of our setup and not through the session? Now, of course, that's going to essentially break our code as it is, but we could code around that. So let's look at how in the next episode.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟