[FrameworkBundle] Extract KernelTestCase from WebTestCase #7704
Conversation
|
I understand you reasoning. not sure if this enough for a BC break so if at all I would go with 2) |
|
|
|
+1 for the second method. |
|
I have a |
|
👍 for the second way |
|
I'm with @lsmith77 for option 2, taking into account Fabien's post about stabilising Symfony. |
|
+1 for the second proposal |
|
👍 for option 2 |
|
Both options are weird imho, because FunctionalTestCase would then have |
|
+1 for the second way |
|
@beberlei I like your suggestion and think it makes better sense. To be more specific, are you suggesting extracting This solution would give us a clear extension point in This solution would also be 100% backwards-compatible. Assuming we proceed with the above, should we stick with |
|
btw LiipFunctionalTestBundle has a method to run commands. maybe we should have another class for command testing? |
|
I'd go with 3. |
|
+1 on |
|
👍 for the suggestion by @beberlei |
|
It might be good to keep WebTestCase but pull most of its functionality up to a new KernelTestCase (or FunctionalTestCase) (option 3). @lsmith77 I'm using your command method, and your fixtures loader, they are very handy. This gives rise to a concern though; what if you have a hierachy like this:
...but you want to use some of the functionality in WebTestCase and CommandTestCase. Perhaps your tests should be in separate classes, but not always. I would this is a good use case for traits, but they require PHP 5.4, so presumably we are a long way off from being able to use this. A monolothic KernelTestCase containing all the above, perhaps (with delegation where possible)? |
|
+1 on option 3. I believe WebTestCase is just as good, or perhaps even better than FunctionalTestCase. What it does is expose getClient(), which is specifically used for testing web requests. Functional tests can be written for other stuff than web requests, and I would assume you could also use the client in non-functional tests. |
|
+1 on option 2. My organization uses Symfony mostly for serving HTTP APIs, where we often asynchronously process data via Symfony commands. A common test scenario for us to make several API requests, do some assertions, run a command to process some data, make a few more requests, and do more assertions. If the test cases are split out into a bunch of different classes, it's not really saving anyone work. |
|
Any news on this issue? Is it worth doing something about the current state? |
|
I will submit a PR for review this weekend based on @beberlei's ideas above. |
|
Just had to explain folks why they need to use the WebTestCase for tests that just need the container. The name is misleading, so ping @johnkary :-) |
Ideal base class that needs access to a Kernel but not a Client such as when testing a Command.
|
I've submitted code for this PR against the 2.4 branch because there are no BC breaks. Docs PR is here and is also against 2.4: symfony/symfony-docs#3244 |
|
New features should be placed in 2.5, no matter if it has bc breaks or not. |
…se (johnkary) This PR was merged into the 2.5-dev branch. Discussion ---------- [FrameworkBundle] Extract KernelTestCase from WebTestCase | Q | A | ------------- | --- | Bug fix? | No | New feature? | Yes | BC breaks? | No | Deprecations? | No | Tests pass? | Yes | Fixed tickets | None | License | MIT | Doc PR | symfony/symfony-docs#3311 Previous discussion is in #7704. Opened new PR to target master branch. This idea came to me while reading the Cookbook article [How to create a Console Command - Testing Commands](http://symfony.com/doc/master/cookbook/console/console_command.html#testing-commands) and I wanted to hear feedback from others before submitting a patch. Basically the Cookbook article states that when testing a Command that extending `WebTestCase` is a good way to get access to the Kernel and thus the Container. This struck me as weird because I was wanting to test a Command, which doesn't really have anything to do with "the web." Currently `WebTestCase` doesn't do anything internally that looks like web-specific work, and the class docblock itself states "WebTestCase is the base class for functional tests.". After a suggestion in #7704 by @beberlei, I decided to take his advice and now have the following implementation: Extracted a new class `KernelTestCase` from `WebTestCase` and instead allow WebTestCase to extend KernelTestCase. Pulled all methods up into KernelTestCase except `createClient()` because `createClient()` is focused solely on creating a Client for issuing web-based requests. Benjamin's solution provides us a clear extension point from `KernelTestCase` for Command-based tests and also provides 100% backwards-compatibility without the need to deprecate WebTestCase. Commits ------- c4f14fb Extract new base test class KernelTestClass
This idea came to me while reading the Cookbook article How to create a Console Command - Testing Commands and I wanted to hear feedback from others before submitting a patch.
Basically the Cookbook article states that when testing a Command that extending
WebTestCaseis a good way to get access to the Kernel and thus the Container. This struck me as weird because I was wanting to test a Command, which doesn't really have anything to do with "the web."Currently
WebTestCasedoesn't do anything internally that looks like web-specific work, and the class docblock itself states "WebTestCase is the base class for functional tests.".I'm not sure how far-reaching this class is used by others, so I'm not sure on the BC implications. I think we could go one of two ways:
UPGRADEdocumentation to note the new class name and action required by someone upgrading their application. This issue should be noticed pretty quickly by anyone upgrading as their test suite would break. But finding the easy fix inUPGRADEshould require little work from project owners.@deprecatedflag for WebTestCase to be removed in Symfony 2.4 after 2.3 LTS. This would ensure all existing bundles using WebTestCase would still work, but we could encourage a more-properly named class starting in 2.4.Do you agree, and if so, which method sounds best?
EDIT 1:
@beberlei made a great third suggestion below that I think is better than the two above:
KernelTestCasefromWebTestCaseand instead allow WebTestCase to extend KernelTestCase. Pull all methods up into KernelTestCase exceptcreateClient()becausecreateClient()is focused solely on creating a Client for issuing web-based requests.Benjamin's solution provides us a clear extension point from
KernelTestCasefor Command-based tests and also provides 100% backwards-compatibility without the need to deprecate WebTestCase.