8000 PHPUnit Tests · Issue #354 · reactphp/reactphp · GitHub
[go: up one dir, main page]

Skip to content
8000

PHPUnit Tests #354

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

Closed
shaunbramley opened this issue Aug 18, 2016 · 10 comments
Closed

PHPUnit Tests #354

shaunbramley opened this issue Aug 18, 2016 · 10 comments

Comments

@shaunbramley
Copy link
shaunbramley commented Aug 18, 2016

References: A. Twitter conversation between myself and @WyriHaximus https://twitter.com/shaunbramley/status/765939778277806080
B. reactphp/child-process#5
C. sebastianbergmann/phpunit#2194

As per @WyriHaximus request within Ref A, I am submitting an issue that affects all reactphp test suites.

As per Ref C, unit tests that execute getMock() with PHPUnit 5.4+ will receive warning messages for each call indicating that the method has been deprecated, as evidenced at Ref B.

Absence of PHPUnit from require-dev, results in the expectation that unit tests will run error free with latest tooling. Yet, when latest tooling is used, tests throw warnings (unexpected behaviour). Part of the issue seems to stem from Ref B, which highlights a decision to avoid referencing PHPUnit as a developmental requirement.

@WyriHaximus
Copy link
Member

Another reason to get phpunit in require-dev is that, maybe combined with a makefile, getting started on testing is easier rather than having to install phpunit seperately. Anther plus side is that you can lock it down to a supported version. I'm all 👍 for this, but interested to hear what @clue, and @jsor think.

@clue
Copy link
Member
clue commented Aug 19, 2016

I understand there are some downsides to adding a dependency on phpunit to our components, but IMHO they really only boil down to a slightly slower (default) installation, which I consider only a minor inconvenience. On the other hand, adding a dependency will result in a more reliable setup with versions that are actually supported and continue to work in the future. In a few years, figuring out which version was supported some time ago is going to much much harder, so I'd suggest rather locking this now.

As such, my vote goes to adding the dependency 👍

@WyriHaximus
Copy link
Member

The good thing is that composer caches this locally. On Travis there are ways to utilize that for (slightly) faster builds.

@jsor
Copy link
Member
jsor commented Aug 20, 2016

👍

@shaunbramley
Copy link
Author
shaunbramley commented Aug 22, 2016

A. PHPUnit 5.5 Release Notes
B. PHPUnit 4.8 Release Notes
C. #350

Ref C somewhat relates, as the version of PHPUnit chosen to "lock onto" may impact the minimal version of PHP that libraries support, which I have noticed varies between individual libraries.

@WyriHaximus
Copy link
Member

Think 4.8 makes most sense with our current supported versions.

@cboden ping; can we move forward or do you have any objections?

@cboden
Copy link
Member
cboden commented Jan 2, 2017

LGTM

@WyriHaximus
Copy link
Member

Awesome!

Ping @shaunbramley do you still want to do this? Otherwise I'll do it 😄 .

@shaunbramley
Copy link
Author

I can certainly start submitting some PR's

@clue
Copy link
Member
clue commented Feb 8, 2017

See all linked PRs :shipit: 🎉

I'll assume this is resolved and will close this for now, please feel free to report back otherwise.

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

No branches or pull requests

5 participants
0