Skip to content

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

Merged
3 commits merged into from
Mar 24, 2021
Merged

Starting recommending to run PHPUnit directly #906

3 commits merged into from
Mar 24, 2021

Conversation

weaverryan
Copy link
Member

Q A
License MIT
Doc issue/PR TODO - important

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 keep bin/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 their phpunit.xml.dist file, all of the features of phpunit-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:

  1. When you composer require test --dev, you actually download symfony/test-pack (this is already the case). In Adding phpunit directly to the pack test-pack#10, I've added phpunit/phpunit. This means you'll get both symfony/phpunit-bridge and phpunit/phpunit.

  2. When the recipes are executed, the symfony/phpunit-bridge runs first. This gives the user the phpunit.xml.dist file from phpunit-bridge, which is good because that has the <listener class="Symfony\Bridge\PhpUnit\SymfonyTestsListener"/> already in it.

  3. At this point, the user can run ./vendor/bin/phpunit directly. But, of course, they could also choose to continue executing simple-phpunit directly. But, as a shortcut (and to make this change smoother), the bin/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 the phpunit-bridge recipe, we have 2 spots where we favor config that assumes you're running things directly.

Cheers!

Copy link

@ghost ghost left a 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>
-->
Copy link
Member Author

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)

Copy link
Member

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');
Copy link
Member Author

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.

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

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already fixed in #952

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

@kbond
Copy link
Member

kbond commented Feb 27, 2021

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.

@wouterj
Copy link
Member

wouterj commented Feb 27, 2021

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

  • The simple way is now targeted at application developers, rather than library maintainers.
  • This removes Symfony being "special with PHPunit". This allows removing some docs about PHPunit, and also allows referencing official PHPunit docs and blog posts.
  • This opens up using many community packages build for/on-top-of PHPunit in a Symfony application, such as Paratest, Collision or PestPHP.
  • The "old way" is still supported (vendor/bin/simple-test), so no feature is lost with this change

@wouterj
Copy link
Member

wouterj commented Feb 27, 2021

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.

@javiereguiluz
Copy link
Member

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!

@Nyholm
Copy link
Member

Nyholm commented Mar 2, 2021

This PR is marked as "[WIP]", what is the current blocker?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Mar 23, 2021

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 --no-dev when installing deps on prod servers, it also means runtime overhead to load functions declared by phpunit et al., exposition to possible unserialize()+destructor exploits, etc.

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.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Mar 23, 2021

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.

@Nyholm
Copy link
Member

Nyholm commented Mar 23, 2021

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.

@nicolas-grekas
Copy link
Member

See also composer/composer#9792

@weaverryan weaverryan changed the title [WIP] Starting recommending to run PHPUnit directly Starting recommending to run PHPUnit directly Mar 24, 2021
Copy link

@ghost ghost left a 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.

@weaverryan
Copy link
Member Author

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 bin/phpunit to use phpunit/phpunit directly. So if you don't get this recipe, then you will still be using phpunit-bridge, which is fine... except that it could cause some class versioning issues where phpunit-bridge downloads one version of PHPUnit, then the user's app has another version autoloading from their own vendor/.

I have just tested this recipe, both with and without phpunit/phpunit directly installed.

@wouterj
Copy link
Member

wouterj commented Mar 24, 2021

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.

Note that we unpack packs by default. So you would need to install a fresh test-pack in a <5.3 application to get this situation afaics

@ghost ghost merged commit 43bdac2 into symfony:master Mar 24, 2021
@weaverryan weaverryan deleted the phpunit-updates branch March 24, 2021 15:29
@weaverryan
Copy link
Member Author

I'm coordinating with Wouter to make sure the docs will be ready for 5.3

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants