Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject methods with mocked dependencies #2

Open
5outh opened this issue Dec 15, 2015 · 4 comments
Open

Inject methods with mocked dependencies #2

5outh opened this issue Dec 15, 2015 · 4 comments

Comments

@5outh
Copy link
Contributor

5outh commented Dec 15, 2015

As of Laravel 5, Controller methods can utilize dependency injection. We should be able to deal with this by proxying the call to each method with a wrapper function call in InjectedTrait.

i.e.

class SomeController
{
    public function someMethod(SomeDependency $dependency)
    {
        // Do stuff...
    }
}

In our tests, I'd like to be able to do:

$controller = $this->make();

$args = $controller->call('someMethod');

$args->dependency->shouldReceive(/*...*/);

The exact way this works is up for debate, but args should not be added directly to the test case, since the names of the dependencies may clash with class dependencies.

@etcinit
Copy link

etcinit commented Dec 15, 2015

I've had a task open on this for Impersonator for a while. I think the hardest part is figuring out what is a dependency and what is not.

Here's how I was planning to implementing it:

// string -> string -> Map<string, mixed> -> mixed
$impersonator->call(SomeClass::class, 'someMethod', ['userId' => 456]);

Everything that is not provided in the arguments array is considered a dependency. The developer is expected to fill out every argument without type hints. Everything else should be a mock previously provided by the developer or automatically mocked.

https://phabricator.chromabits.com/T14

@5outh
Copy link
Contributor Author

5outh commented Dec 15, 2015

Good idea 👍

The nice thing about InjectedTrait is that we'll already have the class name. The other nice thing is that the arguments can default to []! So here I think we can get away minimally with the syntax I mentioned above; I hadn't considered non-injected arguments though!

@etcinit
Copy link

etcinit commented Dec 17, 2015

Another thing to consider is default values. I need to add that. Essentially, if an argument is not provided, we should try to find a default value first before failing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants