On Aug 10, 2007, at 8:22 AM, Ovid wrote:
--- Andy Lester <[EMAIL PROTECTED]> wrote:
I had actually submitted a patch to 'prove' a long time ago which
allowed prove to accept a pattern and only run tests whose
filenames
match said pattern. It was never applied, so I assume Andy has
some
reason why this might not be a good idea. Andy?
Tuits. How long ago was this?
A couple of years ago. I remember following up with you about it, but
I don't recall the outcome other than the patch not being applied. I
seem to recall someone protesting that deliberately choosing a subset
of tests to run is a dodgy practice (it's not), but I doubt it was you
who said that.
But if you give prove multiple test classes (either through a pattern
or directly on the command-line), won't it run each of those classes
as a separate perl process? That seems unnecessarily inefficient,
compared with the typical Test::Class script that loads and runs all
tests in a single process. In fact, reducing test load time was one
of the reasons I initially went with a class-based test approach.
Would it be better for prove to take two additional switches, e.g.
-m <method-pattern>
-c <class-pattern>
and simply set environment variables TEST_METHODS and TEST_CLASSES
respectively before calling the test script? Then Test::Class::Load
could be tweaked to respect the TEST_CLASSES variable, just as
Test::Class respects the TEST_METHODS variable. Obviously, these
switches would be no-ops for traditional test users.
The INIT {} solution (though clever) has other problems - for example
there is no way to just load the test modules without running the
tests. e.g. you might want to load them into a persistent web
environment so that the tests can be run later via a web page.
Jon
