Allow filters with binary

[goatherd]

It would be great to filter files for recursive dictionary scans or to filter class names that are assumed autoloadable but not provided by the bootstrapping.

May either add comma-separated lists with the binary or provide a (xml) config file to do so.

Use cases might be

• avoid paths like */tests/* from being parsed (which might be mixed within libraries for quiet a few frameworks). I am aware that you can use shell tools (like find) for those. It's just the effort to write and debug those commands is quiet high, as it is to name all directories and files wanted to skip a few unwanted ones.
• support extensions like PHPUnit or FirePHP or other optional libraries not provided by bootstrapping

The latter seeming more important to me.

On a side note: Do you mind getting the tool that complex? It's more fun working with you, but if you do not care too much about other frameworks or find it to bothersome just say so.
I did some tests on a phpcs integration which would at least provide file name filters and allows usage of config files. Well, the main reason to do so is to enable pdc with a simple config switch, as phpcs is quiet widely used. Still some further improvement is needed to make it stable enough with major frameworks. Especially on-demand annotation support and stable class name detection.

[mauris]

You mean to say provide exceptions when scanning?

Example.

If \OAuth\RuntimeException is used in the scanned code and is not loaded, but however because it is in the exception list so the error shouldn't show up?

How about using a openssl-alike configuration style? They provide a --config to provide an overriding configuration file.

I don't mind the tool having better detection and wider usage because it can benefit more people. I am more than happy to work with you on that.

[goatherd]

--config would be fine.

You mean to say provide exceptions when scanning?
Yes, that would be a good example.
But even stronger than that: it should not be necessary for the developer using pdc to have any extension available/ installed that may be used somewhere within the tested code. One such use case being an optional extension with classes not used at all when it is not installed. An other being virtual machines used for development and a host-only pdc installation (like pdc hooked on git commit or an IDE).

As for the config format. Assuming xml (human readable, no additional library required) an annotated config might look like:

<?xml version="1.0"?>
<!--
  Project name might be given in report or verbose output.
-->
<pdc name="Some Project">
  <!--
    Specify the project bootstrap.
    Paths are mapped relative to the config file. So either absolute or relative paths are okay.
  -->
  <bootstrap name="app/bootstrap.php" />
  <!--
    List of classes/ interfaces/ traits that are assumed to be autoloadable but may not be provided by the bootstrap.
    May be given as content or name-argument of the tag.

    PDC might be extended at some point to test for correct context of such names. i.e. do not allow to implement a class/ trait, to extend and interface/ trait or class X { use Y; } with an class or interface Y.
  -->
  <classmap>
    <class>OAuth\RuntimeException</class>
    <class>PHPUnit_TestCase</class>
    <trait>SomeTrait</trait>
    <interface name="SomeInterface" />
  </classmap>
  <!--
    Specify files that are passed to PDC.
    Include first, filter by exclude pattern.
    Single wildcard * can extend to file/ dir names only.
    Double wildcard ** can extend to multiple directories (i.e. contain the directory separator '/')
  -->
  <files>
    <include>/path/to/files/*.php</include>
    <include>./rel/path/to/files/**.php</include>
    <exclude>**/tests/**</exclude>
  </files>
</pdc>

Slightly influence by phpunit and phpcs. Naming open to debate. Not sure what is common or is not. The distinction between class, interface and trait is not required but might be useful later on.
What do you think?

[mauris]

currently for folder inclusion you can separate by PATH_SEPARATOR (or ;) like this:

php pdc.phar src;../test/src

[goatherd]

Simply adding multiple paths is insufficient as code might be arbitrarily mixed in that should not be tested. For too many projects it would require you to name files one-by-one since a common path holds something you do not want to test.

The feature is only meant in addition to that existing logic thought.