تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Adding Database Update Test0:00

We now have a test that ensures if you have a Retailer with no corresponding Client, an exception will be thrown. So that takes care of this path here. However, it doesn't include this, because an exception will be thrown before it reaches that point. Now, this is covered in our general feature test, but we might want to add one more test that ensures at a lower level we do update the database. So we might say it updates local stock status after being tracked. And it's basically the same thing. So given we have a Retailer and stock, if we track that stock, well, as part of that, we now know it'll use the client factory to determine the appropriate Client, right? And then it should call a checkAvailability method on the Client.

well, as part of that, we now know it'll use the clientFactory to determine the appropriate client, right? And then it should call a checkAvailability method on the client. So all we have to do, if you think about it, is create a fake version of the client. That client can return a hard-coded response, and then our assertion is the stock is updated according to that. So, for example, if that checkAvailability method returns available is true, and the price is $99, well, let's just make sure that exists in the database. So I could say this assertTrue, and we need the stock. So let's just tap it. Okay, so assert that the stock is in stock. That should be true. And then also the price should be $99.

Faking ClientFactory Response1:35

Okay, so assert that the stock is in stock. That should be true. And then also the price should be $99. And yeah, I mean, that's effectively our test. So if we give it a run, notice it's still trying to make a full HTTP request, and we don't want that. So right here, we've already done the legwork. We have our client factory set up as a real-time facade, as you see right there. So I'm just going to say, well, it should receive a call to make. And actually, I'm going to show you two ways that you can structure this. So to be clear with you, right here, don't forget, this is the class that determines what the corresponding client is. It reads the retailer name and then dynamically instantiates a class based on that.

So to be clear with you, right here, don't forget, this is the class that determines what the corresponding client is. It reads the retailer name and then dynamically instantiates a class based on that. So I don't actually want to trigger this because I want to, it's almost like putting a knife into the middle. I want to intersect this call and return something else instead. So it should receive a call to make, and it's going to return a new FakeClient. And this FakeClient will return this hard-coded results when checkAvailability is triggered. OK, so if I run it, it's going to let me know, can't find that class. All right, just put it right down here at the bottom. Keep it simple. Class FakeClient implements OurClient class. We will add the method stubs.

class FakeClient implements OurClient class. We will add the method stubs. And now, yeah, here, we're now triggering this method rather than the real-life method that will make an HTTP request. So let's return a new StockStatus where the availability, we'll just use an inline temporary variable here. And the price is $99. This is a common technique. We don't need those temporary variables at all. So if I just did this, it's still going to work. However, a side effect is six months from now, I'm not going to remember what true is. And I may not even remember what 99 is.

Anonymous Class Alternative3:35

However, a side effect is six months from now, I'm not going to remember what true is. And I may not even remember what 99 is. But if I bring this back, even though we're not using the variables, it's almost like free documentation. You instantly know what that refers to. So let's give it a run, and ta-da, it works. Kind of a neat trick, don't you think? So let me show you a couple other ways you might structure this. We reference a real class, but you could also reach for a php anonymous class. And all we do here is just instantiate it on the fly like this. And let's bring that in.

Mockery Mock Alternative4:07

And all we do here is just instantiate it on the fly like this. And let's bring that in. Yeah, so now we inline a class that implements the Client. And I think we'll still get green, and we do. So that's an option as well. Rather than manually creating a fake, which I often like to do, you could also use mockery to do this. So you could say, mockery::mock, the ClientInterface, like this. Just showing you some options here. clientMock should receive a call to checkAvailability. And it's going to return this.

Client mock should receive a call to check availability. And it's going to return this. So that would be an option as well, to manually create it as a mock. I often like being a little more verbose in these cases. It more closely matches the actual code. Yeah, then I could say this. So our ClientFactory is going to receive a call to make, and it's going to return a client mock. Now, if we give it a run, no, we forgot to import mockery. Okay, one more time. And yeah, we get green as well.

Mock Chained Factory Call5:16

Okay, one more time. And yeah, we get green as well. It's the same basic concept. But here's one last approach. If I go back to the Stock model, notice this Retailer Client, so that's going to run ClientFactory::make(). And then we call a checkAvailability() method on that response. So we could alternatively write this like so. ClientFactory should receive a call to make(), and then checkAvailability() on that result. And then it's going to return a new StockStatus. And I'll paste that in.

And then it's going to return a new stock status. And I'll paste that in. So this, I believe, should work as well, and it does. So that's kind of a neat approach as well. Create a mock for ClientFactory. Expect a call to make. And then what's returned from that, I also want to be a mock. And then expect a call to checkAvailability, and then return this. So that's a more verbose option that you should consider. And that will work as well.

Finalize Test and Run Suite6:07

So that's a more verbose option that you should consider. And that will work as well. So now we've covered the full surface area. If I comment that out, the test is going to fail. So that's good. We can get rid of all of this. Here's our test. So reformat, run it. That's passing. And then if I run the full suite, that's passing as well.

That's passing. And then if I run the full suite, that's passing as well. Okay, we've waited long enough. In the next episode, it's time to create an actual BestBuy client.

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