Skip to content
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

Refactor how filtering works #386

Open
sebastianbergmann opened this issue Sep 23, 2015 · 3 comments
Open

Refactor how filtering works #386

sebastianbergmann opened this issue Sep 23, 2015 · 3 comments

Comments

@sebastianbergmann
Copy link
Owner

sebastianbergmann commented Sep 23, 2015

Right now, File_Iterator is used to crawl the filesystem for files that match the criteria specified in the (PHPUnit) configuration resulting in a list (array) of files that are to be included in the code coverage report. This crawling is responsible for a slowdown in the startup of PHPUnit.

It would be better to store the information ("all *.php files in directory src) instead and match the filenames against that instead of a list generated through crawling.

@sebastianbergmann sebastianbergmann changed the title Refactor how the blacklist/whitelist filtering works Refactor how the whitelist filtering works Oct 3, 2015
@alister
Copy link

alister commented May 27, 2016

Also, if you exclude a directory,

<filter><whitelist><exclude>
      <directory>vendor</directory>

even if there are no files that have previously been white-listed within the directory, PHP_CodeCoverage_Filter::removeDirectoryFromWhitelist will collect the entire file list and attempt to unset the whitelist of each file.

@sebastianbergmann sebastianbergmann changed the title Refactor how the whitelist filtering works Refactor how filtering works Jun 7, 2020
@AndrewFeeney
Copy link

@sebastianbergmann Is your proposal here that we should have a single flat map of files in an array or object instead of a recursive nested directory tree? Would that array or object then be included with the serialized output?

@sebastianbergmann
Copy link
Owner Author

Is your proposal here that we should have a single flat map of files in an array

That is the status quo and what I meant in #386 (comment) when I wrote "list (array) of files that are to be included in the code coverage report".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants