Oh, by the way, I updated the example of controller testing on my blog,
extracting the mock instantiation into a dedicated method, that should give
a better idea of what I mean, thanks.

On Tue, Oct 5, 2010 at 10:58 AM, Bulat Shakirzyanov <[email protected]>wrote:

> Hi Lukas,
>
> I personally don't think its possible to refactor the mock setup and reduce
> duplication.
> It might seem annoying that you have to instantiate mocks all the time and
> pass 6-7 parameters, but the mocks are very domain specific, as they are to
> test how your application interacts with them.
> Therefore, depending on circumstances, you might want to mock all methods
> or just a couple, you might want to invoke constructors or original methods
> or not - everything is very very domain specific and I don't see a universal
> cure.
> I do refactor my tests suites, by extracting common mock instantiation
> first into dedicated methods inside the test class, and then into bundle
> specific dedicated test cases (ForumBundleTestCase) that most of my bundle
> specific tests then extend.
> There are many more ways of refactoring tests, and a couple of good books
> written on the topic (http://xunitpatterns.com/), but there isn't a
> universal solution.
> And I think it would be a lot of effort to create one, simply due to the
> nature of tests.
>
> Remember, tests, just like the application code, are very specific to the
> problems you're solving.
>
> What I see possible however is for Symfony2 to provide ApplicationTestCase,
> where you could get mocked instances of Templating engine, and other widely
> used services (don't use others that much), which you could then extend to
> not write the same functions twice.
>
> Thoughts?
>
> Best,
> Bulat
>
> On Tue, Oct 5, 2010 at 8:17 AM, Lukas Kahwe Smith <[email protected]>wrote:
>
>> Hi,
>>
>> If you look at Bulat's recent controller testing example you can see that
>> he needs to mock the templating service:
>> http://avalanche123.com/post/1215273326/symfony2-controller-testing
>>
>> As you can see in the comments, its actually not that easy, since the
>> templating service needs to be told to either not call the constructor or it
>> needs yet another services mocked and injected.
>>
>> Now imho it would be nice if the DIC would provide some solution to
>> automate the creation of mock objects. Obviously one would still need access
>> to the mock objects (which might not be guaranteed in all cases) in order to
>> add expects() etc. But it could be a huge timesaver.
>>
>> 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
>>
>
>

-- 
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

Reply via email to