Now, in the previous episode, we manually created this dummy Gateway class. And that required creating the file, adding the class, and then implementing the interface. And this is fine. It's easy to understand, it's configurable, it's great. However, if you'd rather automate this process, there are ways to do so pretty easily. I'll show you how. Let's switch back. And now, rather than referencing that file we created, we'll instead ask phpUnit to create a mock. And specifically, I want to mock the Gateway class.

create a mock. And specifically, I want to mock the gateway class. Okay, but now you're probably thinking, wait a minute, we haven't even gotten to that term mock. We're still on dummies. So what's going on here? And yep, you're right. This is where things do get confusing. I think you'll often find that people use the term mock as a general term to reference any kind of test double.

Okay. Anyhow, let's go ahead and give this a run. I will just do this inline, and it passes. Which means you, again, this is optional. Some people prefer to manually create their dummies or their mocks. In my case, I usually only manually create the file if there's a good reason to it. If I think it's easier to reason about, or I need a little bit more control. Otherwise, I will use createMock, or as I'll show you later, there's a dedicated tool called Mockery that provides maybe a nicer API for creating mocks and declaring your expectations. So now we can see gateway is only used once.

Mockery that provides maybe a nicer API for creating mocks and declaring your expectations. So now we can see gateway is only used once. So why don't I go ahead and inline that, and this is what we get. It passes. So here's what's going on. When I create mock, it's going to whip up an object that implements this type. Now any methods, you'll see here create, or here's our implementation. Any methods like this, when called, will simply return null. It's not going to do anything. So in these situations, you'll find that a test dummy is often only there to fill a

It's not going to do anything. So in these situations, you'll find that a test dummy is often only there to fill a parameter list. A subscription needs a gateway to work. We don't really care about the gateway for the tests we're writing, but we still need to pass something as that parameter. So this is when you would reach for a dummy. But what about, as we prepare for the next episode, the situations where a dummy isn't enough? You need to say, okay, well, when this create method is called, I do expect it to return

enough? You need to say, okay, well, when this create method is called, I do expect it to return some kind of value. Maybe that value should be foobar, because potentially that would then be passed somewhere else. And you'll need to perform assertions against that. Okay, well, this is where we start to get into the territory of a stub. So in the next episode, we'll talk a bit more about the differences between the two, as well as the practicality of how to create a stub and have your methods return predefined values.

well as the practicality of how to create a stub and have your methods return predefined values.