-
-
Notifications
You must be signed in to change notification settings - Fork 492
Starting recommending to run PHPUnit directly #906
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request passes validation.
<extensions> | ||
<extension class="Symfony\Component\Panther\ServerExtension" /> | ||
</extensions> | ||
--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just to make this file consistent with the phpunit.xml.dist
file from the phpunit-bridge
recipe, in case someone installs phpunit
directly (and not via the pack, where you will get the phpunit.xml.dist
file from phpunit-bridge
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nice addition would be to have a PHPUnit configurator in Flex.
#!/usr/bin/env php | ||
<?php | ||
if (file_exists(dirname(__DIR__).'/vendor/phpunit/phpunit/phpunit')) { | ||
require(dirname(__DIR__).'/vendor/phpunit/phpunit/phpunit'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the new part: if PHPUnit is install directly, use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried adding this to my bin/phpunit file and I'm getting
PHP Fatal error: strict_types declaration must be the very first statement in the script
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you try without strict type declaration?
This file don't include any.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already fixed in #952
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already fixed in #952
Indeed, thanks
I recently switched a large (4.4) app over to using paratest (with excellent results btw). Since paratest (and I believe we want to start promoting this) requires phpunit I switched to requiring phpunit directly in my app without issue. |
👍 I like this approach! I'm not sure what my approval triggers on flex recipes, so I'll leave this as a normal comment for now :) A couple important takeaways from this PR imho:
|
Btw, I'm going to work on a testing docs rewrite soon (see symfony/symfony-docs#14731). It would be great to coordinate merging this together with the doc changes, so less resources are spent and a bigger "announcement" can be made. |
In my opinion, this hits the sweet spot: it allows to use standard PHPUnit practices while enjoying all the cool features of Symfony's PHPUnit Bridge. A big 👍 form me. Thanks Ryan! |
This PR is marked as "[WIP]", what is the current blocker? |
I'm certainly not happy with this PR, because requiring phpunit/phpunit as a direct dep is conceptually so wrong. Sebastian Bergmann himself discourages doing so. Yet everybody happily does it and 🙈 with the issues it creates. Dependency hell is the first and major one, but since the majority doesn't use I don't have the will to block this move, because I also understand ppl that complain about simple-phpunit - it's not a perfect solution either. I think the tradeoffs it offers are worth it, but if the majority doesn't agree, let's merge. 👍 from the purely technical aspect for the patch. |
For the record, see composer/composer#9636, which looks for a better solution to these issues. No ready, so not a blocker for this PR. |
I do see your point and I agree that this is an issue that should be solved. But it is not a "symfony issue", it is more an issue of how the php community is using tools like phpunit. I think symfony would benefit to do "like everybody else" in this case, even though it is a technically worse solution. |
See also composer/composer#9792 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request passes validation.
Here's the plan: A) Merge this recipe. It applies to phpunit-bridge 5.3 only. B) When 5.3 comes out, THEN merge and tag adding phpunit/phpunit to test-pack symfony/test-pack#10 The timing on (B) is just to reduce (but definitely not eliminate, think 4.4. users) the number of people who would install test-pack but not get the new recipe. This recipe updates I have just tested this recipe, both with and without |
Note that we unpack packs by default. So you would need to install a fresh |
I'm coordinating with Wouter to make sure the docs will be ready for 5.3 |
Hi!
This is tricky, and probably controversial. My goal is to make running PHPUnit in Symfony projects "not special". This means that users can run
./vendor/bin/phpunit
like any other project (though, we will keepbin/phpunit
as a shortcut and smooth mechanism to not break docs, etc).My understanding (please correct me if I'm wrong) is that as long as users have
<listener class="Symfony\Bridge\PhpUnit\SymfonyTestsListener"/>
in theirphpunit.xml.dist
file, all of the features ofphpunit-bridge
are available to them. The one exception is the ability to run your tests against multiple PHPUnit versions, which is not a need that many projects have.On a high level, here is how the new system would work:
When you
composer require test --dev
, you actually downloadsymfony/test-pack
(this is already the case). In Adding phpunit directly to the pack test-pack#10, I've addedphpunit/phpunit
. This means you'll get bothsymfony/phpunit-bridge
andphpunit/phpunit
.When the recipes are executed, the
symfony/phpunit-bridge
runs first. This gives the user thephpunit.xml.dist
file fromphpunit-bridge
, which is good because that has the<listener class="Symfony\Bridge\PhpUnit\SymfonyTestsListener"/>
already in it.At this point, the user can run
./vendor/bin/phpunit
directly. But, of course, they could also choose to continue executingsimple-phpunit
directly. But, as a shortcut (and to make this change smoother), thebin/phpunit
file still exists, but now executes PHPUnit directly if it's installed directly.Details
A) The experience has been optimized for the "main" user that just wants to run PHPUnit directly. In the
phpunit.xml.dist
file from thephpunit-bridge
recipe, we have 2 spots where we favor config that assumes you're running things directly.Cheers!