It doesnt make sense to rely on inheritance for adding features like fixture loading or html5 validation. The Bundle should instead provide a base class that gives convenient access to the DIC from which the user can then get services for the different tasks.
This is a valid point. I was reading this article: http://symfony.com/doc/current/cookbook/testing/doctrine.html
I realized that if I want to mock Doctrine stuff, it's easier (I think) to use the OrmTestCase. But if I use your bundle, I have access to the serviceContainer so I can mock services very easily. There is no way to inherit from both so I don't know how to take advantage of both features. Obviously if we had mixin support, this could be easily solved.
Once we have refactor test tools as a services (like fixtures, html5, etc...) then we should find a way to register/access them, this can be done:
I've started to work on this as part of #132. A work-in-progress branch is available in our fork at https://github.com/comsolit/LiipFunctionalTestBundle
@lsmith77 hi, do you still hope to implement this feature? While extracting the data fixtures methods from WebTestCase to a new class (see alexislefebvre#21), I was able to create a service for the fixtures: alexislefebvre@79cea44
Are you interested in this? There is still some work though (do the same for the form validator?) but the idea is validated: the service works and it doesn't break the current tests.
alexislefebvre#21 is a huge PR, I can't split it: refactoring of loadFixtures() in smaller functions and moving of the code to Utils/FixturesLoader.php.
yeah. dont think that throwing everything into one base class is such a great design. but this is obviously more of a 2.0 topic. but if you are motivated there is also the other open PR marked for 2.0
I think we can already split fixtures and assertions in new classes, but I see one drawback: it would break postFixtureSetup(), etc. functions which are called in the current loadFixtures() function. If WebTestCase use these new classes these functions won't be called.
Without this Backward Compatibility we could publish a 1.5 version which provide new services and work with tests classes extending WebTestCase. Then publishing a 1.6 version deprecating the inheritance from WebTestCase. With the 2.0 version we could remove these deprecated features.
About the other PR, I'm sorry but I'm not interested in the idea. I don't think it's much easier than loading fixtures.
@lsmith77 I moved response assertions to a new class, what do you think of this other PR? A test inheriting from Symfony's WebTestCase can use the assertions from the LiipFunctionalTestBundle's WebTestCase. I think it's pretty cool. :)