How to mock a service (or a ServiceProvider) when

问题:

I'm writing a small API in Laravel, partly for the purposes of learning this framework. I think I have spotted a gaping hole in the docs, but it may be due to my not understanding the "Laravel way" to do what I want.

I am writing an HTTP API to, amongst other things, list, create and delete system users on a Linux server. The structure is like so:

• Routes to /v1/users connect GET, POST and DELETE verbs to controller methods get, create and delete respectively.
• The controller App\Http\Controllers\UserController does not actually run system calls, that is done by a service App\Services\Users.
• The service is created by a ServiceProvider App\Providers\Server\Users that registers a singleton of the service on a deferred basis.
• The service is instantiated by Laravel automatically and auto-injected into the controller's constructor.

OK, so this all works. I have also written some test code, like so:

public function testGetUsers()
{
    $response = $this->json('GET', '/v1/users');
    /* @var $response \Illuminate\Http\JsonResponse */

    $response
        ->assertStatus(200)
        ->assertJson(['ok' => true, ]);
}

This also works fine. However, this uses the normal bindings for the UserService, and I want to put a dummy/mock in here instead.

I think I need to change my UserService to an interface, which is easy, but I am not sure how to tell the underlying test system that I want it to run my controller, but with a non-standard service. I see App::bind() cropping up in Stack Overflow answers when researching this, but App is not automatically in scope in artisan-generated tests, so it feels like clutching at straws.

How can I instantiate a dummy service and then send it to Laravel when testing, so it does not use the standard ServiceProvider instead?

回答1:

The obvious way is to re-bind the implementation in setUp().

Make your self a new UserTestCase (or edit the one provided by Laravel) and add:

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;

    protected function setUp()
    {
        parent::setUp();

        app()->bind(YourService::class, function() { // not a service provider but the target of service provider
            return new YourFakeService();
        });
    }
}

class YourFakeService {} // I personally keep fakes in the test files itself if they are short

---

Register providers conditionally based on environment (put this in AppServiceProvider.php or any other provider that you designate for this task - ConditionalLoaderServiceProvider.php or whatever) in register() method

if (app()->environment('testing')) {
    app()->register(FakeUserProvider::class);
} else {
    app()->register(UserProvider::class);
}

Note: drawback is that list of providers is on two places one in config/app.php and one in the AppServiceProvider.php

回答2:

Aha, I have found a temporary solution. I'll post it here, and then explain how it can be improved.

<?php

namespace Tests\Feature;

use Tests\TestCase;
use \App\Services\Users as UsersService;

class UsersTest extends TestCase
{
    /**
     * Checks the listing of users
     *
     * @return void
     */
    public function testGetUsers()
    {
        $this->app->bind(UsersService::class, function() {
            return new UsersDummy();
        });

        $response = $this->json('GET', '/v1/users');

        $response
            ->assertStatus(200)
            ->assertJson(['ok' => true, ]);
    }
}

class UsersDummy extends UsersService
{
    public function listUsers()
    {
        return ['tom', 'dick', 'harry', ];
    }
}

This injects a DI binding so that the default ServiceProvider does not need to kick in. If I add some debug code to $response like so:

/* @var $response \Illuminate\Http\JsonResponse */
print_r($response->getData(true));

then I get this output:

Array
(
    [ok] => 1
    [users] => Array
        (
            [0] => tom
            [1] => dick
            [2] => harry
        )

)

This has allowed me to create a test with a boundary drawn around the PHP, and no calls are made to the test box to interact with the user system.

I will next investigate whether my controller's constructor can be changed from a concrete implementation hint (\App\Services\Users) to an interface, so that my test implementation does not need to extend from the real one.