Coverage

[julianseeger]

This PR adds "--coverage-html", "--coverage-clover" and "--coverage-php" to paratest.
(Additionally it fixes some tests that failed before. Probably because of some updated dependencies. The ResultPrinter of PHPUnit now uses "ms")

Why?
Referencing to #57, coverage is NOT antithetical to paratest (@giorgiosironi).
If paratest is a tool to run tests faster, then it's nice to speed up a long-running Testsuite.
But it is even nicer to speed up a super-painful-long-running coverage-enabled run on this long-running Testsuite.
I've seen Testsuites where the coverage-enabled run took about 12000% the time of a run without coverage, so speeding up coverage is even more timesaving.

What?
Like the --log-junit for the testresults, every process creates it's own coverage file at /tmp/COVERAGE_%TESTID%.php (coverage-php).
After every test has finished, those files are read, unserialized, merged (the functionality already existed at \PHP_CodeCoverage) and written with the requested format.

[brianium]

Awesome. Thanks for this.

[julianseeger]

Pleasure ;)

Just to state it, the build passed (https://travis-ci.org/julianseeger/paratest) on my fork.
The Failed build here is because of some timeout. This project has some serious problems with the testsuite. I mean seriously .. 5 minutes for 190 tests? Contributing is nearly impossible with such a misbehaving testsuite.

Probably a rerun of the travis build will pass. (Please don't cite me on this XD )

[brianium]

Some of the changes added with the WrapperRunner have made the testsuite a little unwieldy - especially when testing under windows as it is a *nix only feature. As far as tests taking a long time to run - this is definitely due to the functional suite. I think these tests are extremely valuable, but maybe there is a way to cut down on some of them or better organize them?

[julianseeger]

Yay, fixed!
Travis says "All is well", so are we good to merge?

PS: I don't think that the functional suite contains actually minutes-long tests. It is some loop in phpunit (after those tests have finished) that seem to be corrupted as soon as a test runs a test itself. Some bug deep deep inside...

[brianium]

I'm not opposed to merging this. Would you mind updating the documentation to include this option? I'm noticing as paratest supports more and more features available in PHPUnit, the PHPUnit Tester is growing in size. There is likely a cleaner way to plugin feature support - or configurations in general.

[giorgiosironi]

I see the use case now, I am favorable to include this feature.

[julianseeger]

I am going to add the Documentation and some more tests this weekend.
Am 01.11.2013 10:21 schrieb "Giorgio Sironi" [email protected]:

I see the use case now, I am favorable to include this feature.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/64#issuecomment-27554665
.

[tiger-seo]

Hi guys,
When this going to be merged?
Thank you

[julianseeger]

Probably as soon as I do what I promised.
Sorry, I got stuck at some tests but will finish these tests (including the documentation) soon.

[julianseeger]

Ok, the README includes coverage now, the tempfiles for coverage are unique and get removed after they got merged.

[tiger-seo]

Cool, than it's @brianium step next?

[julianseeger]

Yep ;)

[brianium]

Looks good @julianseeger ! Thanks for your contribution - I am going to push and tag a new release.

[meltzow]

Hi,

my PHPCoverageFile doesn't contains any serialized PHP stuff. So I get an
Notice: unserialize(): Error at offset 0 of 975039 bytes in //vendor/brianium/paratest/src/ParaTest/Runners/PHPUnit/Runner.php on line 324

is it because of this?: sebastianbergmann/php-code-coverage#186

Can anyone help me?

Thank you

[aik099]

I'm using PHPUnit 3.7.* and all is working fine. @wuendsch , are you using dev-master of PHPUnit?