@Loïc Indeed, I could argue that at that point it really becomes a functional test, since the bootstrap of the kernel is still required. I do however see your point and agree that for functional tests it could be very useful: e.g. you could, for example, mock out database connection and run full interaction test much faster. So thanks for giving me this idea, I will not overlook that possibility anymore.
On Thu, Sep 23, 2010 at 10:16 AM, Loïc Frering <[email protected]>wrote: > @Lukas, yes just for testing, it would be quite confusing otherwise. > > @Bulat, it is a good approach also. An other thing you can do with PHPUnit > is: > > $mockAuthService = $this->getMock('Application\Service\AuthService'); > // configure PHPUnit Mock > $mockAuthService->expect() > // ... > $container->set("auth.service", $mockAuthService); > or directly as you wrote: > $controller->setAuthService($mockAuthService); > > By the way, what I meant is that you can just overload your annotation > definition with something like that: > > services: > auth.service: > class: Test\*Mock*\Service\*Mock*AuthService > arguments: [...] > > Then nothing more to do in your tests: the controller is configured by the > DIC which inject his dependencies. But for tests purpose the implementation > is not the same: the mock service will be injected and the test code does > not have to worry or even know about that. That is the flexibility provided > by DI, from Wikipedia <http://en.wikipedia.org/wiki/Dependency_injection>: > "[DI] is useful in unit > testing<http://en.wikipedia.org/wiki/Unit_testing>because it is easy to > inject a fake > implementation <http://en.wikipedia.org/wiki/Mock_object> of a service > into the object being tested by changing the configuration file." > > > On Thu, Sep 23, 2010 at 3:56 PM, Lukas Kahwe Smith <[email protected]>wrote: > >> >> On 23.09.2010, at 15:52, Loïc Frering wrote: >> >> > By overloading the configuration I just mentioned that it could be >> possible when you want to unit test your controller to inject a mock service >> instead of the real implementation as long as testing with the real >> implementation means already be doing integration tests. This overloading is >> "just" defining a service definition with the same id as another that will >> be loaded when tests are run. >> >> right .. overloading is ok for testing ... but should not be used for >> normal operations. >> >> regards, >> Lukas Kahwe Smith >> [email protected] >> >> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected]<symfony-devs%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> > > > > -- > Loïc Frering > [email protected] > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
