Replacing IOC bindings in tests doesn't work about laravel-zero HOT 19 CLOSED

After our discussion in Slack, Nuno found the issue:

The command is instantiated while bootstrapping everything (eg. building the application, etc.), so adding a mock into the container will not register with the command. To temporarily fix this, I've added the following method to my TestCase class to resolve the command out of the container again (with the right dependencies), and add it back to the application:

/**
 * @param string $command
 * @param array  $arguments
 */
protected function call($command, array $arguments = [])
{
    $command = $this->app->getContainer()->make($command);

    $this->app->add($command);

    $this->app->call($command->getName(), $arguments);
}

This way, we can do the following in the tests:

/** @test */
function it_tests_a_mocked_dependency()
{
    $mock = $this->createMock(TestService::class);

    $this->app->getContainer()->instance(TestService::class, $mock);

    $mock->expects($this->once())->method('someMethod')->willReturn('from the tests');

    $this->call(HelloCommand::class);
}

Thanks, @nunomaduro for the help!

from laravel-zero.

@sandervanhooft You want to make sure a command is called right?

from laravel-zero.

I let you think about this, just make sure you prototype something quick and let's think about the real implementation later 👍

from laravel-zero.

After a bit of debugging by @rickbolton and myself, we found this line, which we thought was the perpetrator. We thought changing that to Container::getInstance() instead of manually newing up the container (like it is now) would fix the issue, but it didn't.

Will do some more digging!

from laravel-zero.

Thanks for this. I just spent a day fighting with this issue.

from laravel-zero.

Is there a way to only bind and not call the mocked command? I am trying to test that executing command A (non-mocked) after completion calls command B (mocked).

from laravel-zero.

Hi @nunomaduro , yes that's right.

from laravel-zero.

Meanwhile, I'm testing the solution offered by @svenluijten:

1. I receive an error that the call() method should be made public instead of protected. So I did.
2. Then I receive another error:

Call to undefined method LaravelZero\Framework\Application::getContainer()

This is triggered for this line from Sven's example:

$this->app->getContainer()->instance(PaymentListCommand::class, $mock);

from laravel-zero.

The only non-basic thing is that I have Console Dusk installed.

from laravel-zero.

@sandervanhooft You want to make sure a command is called right?

Yes, but the command I want to make sure is called is called indirectly from another command.

from laravel-zero.

@sandervanhooft A solution may be have a class service that does the real job from the secondary command. And then, mock that service class using the container.

from laravel-zero.

I'm going to dive a bit deeper into this in the next few days (hopefully), will let you know how it goes!

So far absolutely 💗💗 Laravel Zero by the way!

And however briefly - nice to meet you at Laracon.eu!

from laravel-zero.

@sandervanhooft A solution may be have a class service that does the real job from the secondary command. And then, mock that service class using the container.

May be an interesting approach, but I think the assertCommandCalled will be a recurring theme in my app and probably in other devs' as well.

from laravel-zero.

Hummmm. Could you think about an implementation for that? Would be good to add it to Laravel Zero or even to Laravel itself.

from laravel-zero.

Absolutely no idea yet. May need to implement a spy on the Kernel?

from laravel-zero.

Did a quick scan, I can think of three directions currently:

1. Inspired by Event::fake(), wrap Illuminate\Command in a spy when using Command:spy helper. Then use a assertCommandCalled($command, ?$callback) test helper for asserting. It seems impossible to me to go a level deeper because then we get into Symphony territory.

2. Add lifecycle Events to the Command calls (like Eloquent model has) and track these using Event::fake() and Event::assertDispatched(...)

3. Do both. But that's a bit much atm.

What do you think?

from laravel-zero.

(1. "feels" possible, but will be a stretch for me so may take some time)

from laravel-zero.

@sandervanhooft Can you create a new issue with the content of that proposal? Sorry, but I would like to really follow this.

from laravel-zero.

@nunomaduro Done. See #178.

from laravel-zero.