🏝 If you like the content of this blog, I would really appreciate your vote in Tuple's Send an Open Source Developer on Vacation contest. Just search for "Freek Van der Herten" in the nominees list and cast your vote. 🙌

😀 This holiday won't only be a nice reward for me, but also for my girlfriend who always gives me a lot of time working on open source packages and blog posts.

Three types of mocks

Original – by Brent Roose – 3 minute read

Mocking, faking; these might sound like intimidating words if you don't know what they are about, but once you do, you'll be able to improve your testing skills significantly.

Part of "the art of testing" is being able to test code in some level of isolation to make sure a test suite is trustworthy and versatile. These topics are so important that we actually made five or six videos on them in our Testing Laravel course.

In this post, I want to share three ways how you can deal with mocking and faking. Let's dive in!

Laravel's Fakes

Laravel has seven fakes — eight if you count time as well:

  • Bus
  • Event
  • HTTP
  • Mail
  • Notification
  • Queue
  • Storage
  • Time

Laravel fakes are useful because they are built-in ways to disable some of the core parts of the framework during testing while still being able to make assertions on them. Here's an example of using the Storage fake to assert whether a file would have been saved in the correct place if the code was run for real, outside of your test suite:


$post = BlogPost::factory()->create();



Laravel has built-in support for Mockery, a library that allows you to create mocks — fake implementations of a class — on the fly.

Here we create an example of an RssRepository, so that we won't perform an actual HTTP request, but instead return some dummy data:

$rss = $this->mock(
    function (MockInterface $mock) {
                new RssEntry(/* … */)

You can imagine how using mocks can significantly impact the performance and reliability of your test suite.

Handcrafted mocks

Mockery can sometimes feel heavy or complex, depending on your use case. My personal preference is to use handcrafted mocks instead: a different implementation of an existing class, one that you register in Laravel's container when running tests. Here's an example:

class RssRepositoryFake extends RssRepository
    public function fetch(string $url): Collection
        return collect([
            new RssEntry(/* … */),

    public static function setUp(): void
        self::$urls = [];

            new self(),

By cleverly using the service container, we can override our real RssRepository by one that doesn't actually perform any HTTP requests. If you're curious to learn more about them, you can check out our Testing Laravel course.

Stay up to date with all things Laravel, PHP, and JavaScript.

Follow me on Twitter. I regularly tweet out programming tips, and what I myself have learned in ongoing projects.

Every month I send out a newsletter containing lots of interesting stuff for the modern PHP developer.

Expect quick tips & tricks, interesting tutorials, opinions and packages. Because I work with Laravel every day there is an emphasis on that framework.

Rest assured that I will only use your email address to send you the newsletter and will not use it for any other purposes.


What are your thoughts on "Three types of mocks"?

Want to join the conversation? Log in or create an account to post a comment.