Ability to disable coverage generation.

Question

Ability to disable coverage generation.

TomSchillemans opened this issue 7 years ago · comments

Running phpspec with coverage brings my total tests (5 right now) to a 1 to 1.5second execution time.
While running it without coverage (by commenting out the configuration) has a 100ms or less execution time.

Is it possible that we can run phpspec like: phpspec run --no-coverage or maybe even turn it around like
phpspec run --coverage like phpunit has it?

Since I don't nessecarilly want to ALWAYS generate coverage, especially at development.

ek9 · Answer 1 · Tue Oct 17 2017 01:30:33 GMT+0800 (China Standard Time)

Thank you for input. I believe this would be a good enhancement. Would you be willing to submit a PR for this functionality?

A quick workaround for now could be to use separate configuration files (phpspec.yml), one with coverage and one without.

Thanks again.

Michaël Jacobs · Answer 2 · Tue Oct 17 2017 01:32:45 GMT+0800 (China Standard Time)

That's exactly what I ended up doing, in the meantime... :-)

ek9 · Answer 3 · Tue Oct 17 2017 01:37:54 GMT+0800 (China Standard Time)

Actually, I have noticed just now that there is a --no-code-generation when running in phpspec. Could you check that it works as intended and disables code generation? Wouldn't that accomplish same result?

Michaël Jacobs · Answer 4 · Tue Oct 17 2017 01:39:39 GMT+0800 (China Standard Time)

I don't think it's the same?

This disables the "automatic code generation".

Function lorem does not exist. Do you want to generate it? (Y/n)

Don't think it has anything to do with generating code coverage for spec tests? ;)

ek9 · Answer 5 · Tue Oct 17 2017 01:40:38 GMT+0800 (China Standard Time)

Oh yes, my bad.

dannylewis-sheffield · Answer 6 · Thu Mar 15 2018 18:26:25 GMT+0800 (China Standard Time)

I've created a pull request to add this functionality.

#20

Run with code coverage:
bin/phpspec run --coverage

Run without code coverage:
bin/phpspec run

ek9 · Answer 7 · Mon Mar 19 2018 07:31:58 GMT+0800 (China Standard Time)

There is --no-coverage as of version v4.1.1 of extension which accomplishes this.

Thank you everyone for contributing. Closing.

Christian Daguerre · Answer 8 · Fri Jun 08 2018 22:25:58 GMT+0800 (China Standard Time)

The opposite would have been more standard, think of phpunit, it only generates code-coverage reports if you add --coverage and doesnt generate any by default...
Typically you dont want code coverage in dev env and would enable it in CI explicitely...
Do you mind me submitting a MR to invert this?

ek9 · Answer 9 · Sat Jun 30 2018 23:32:23 GMT+0800 (China Standard Time)

@cdaguerre @TomSchillemans let me first start by saying that I don't really mind having additional options in the package to support that and I would happily accept the PR for additional feature, however I feel like it's necessary to clarify regarding why the current behaviour is (semi-)consistent with that of phpunit and why just need to implement an additional feature (and not invert what was already implemented).

First, there are 23 ways one can use phpunit's code generation:

By having a phpunit.xml config where you specify phpunit's configuration (including options for code coverage, including the paths where reports are generated). When that is the case, both phpunit and this extension allows you to use --no-coverage to ignore Code Coverage configuration. This part is consistent with phpunit.
By supplying Code Coverage configuration to phpunit via arguments passed via CLI (you can still optionally have phpunit.xml for generic cases). This allows you to enable code coverage gathering
all the time, but generate reports only when you supply specific arguments to phpunit (i.e. --coverage-html <path>, --coverage-text etc.). We currently do not have this and would need to implement this in a PR
(Updated) You can have a generic phpunit.xml.dist which is the git repository and has CI specific configuration, while the developers could always customize it by providing a phpunit.xml instead (the latter would never be checked into git and allow you to control how phpunit works on developers machine). This feature is really out of scope for this extension

To summarize, we would need to implement a feature to support specifying code coverage configuration parameters via cli instead of only supporting configuration file. I will make a separate issue for this and have a look if I can sort this out during the weekend.

ek9 · Answer 10 · Sat Jun 30 2018 23:43:38 GMT+0800 (China Standard Time)

p.s. There is even a third-case in phpunit which would also allow you to accomplish the same thing: You can have a generic phpunit.xml.dist which is the git repository and has CI specific configuration, while the developers could always customize it by providing a phpunit.xml instead (the latter would never be checked into git and allow you to control how phpunit works on developers machine). This feature is really out of scope for this extension