I just submitted a patch for Test::Class. It lets you do this:
TEST_METHOD='.*customer.*' prove t/test_class.t
And that lets you run only those tests with the string "customer" in the method name. The value of the environment variable is a regular expression bound to the beginning and end of the string, so "customer" would only run tests whose method name is "customer". Of course, setup and teardown methods still run.
Right now, our full suite of data store tests takes about two minutes to run. With TEST_METHOD, I can just run the test on the current test method I'm working on (which takes about 9 seconds) and when I get it passing, pull out the environment variable and run the full test suite. This makes for much faster development and a happy Ovid. I want the test suites to bend to my will, not the other way around.
I'm hoping that this patch or a variant of it is accepted.
It'll go in
I'm gonna mark it as experimental though - since I'm not 100% that some other stuff that I'm playing with at the moment won''t do this in a better way... but the play area is some time from release.
Re:All right all ready!
Ovid on 2006-02-08T15:51:04
Yay! I can easily believe that mine is not the best approach. It just seemed the easiest for me to implement.
Will your approach allow one to specify the test name/names on the command line? That way, a good editor like vi or emacs can figure out the test that it's in and hand that name off for it to be run.
Re:All right all ready!
Adrian on 2006-02-08T16:15:17
Will your approach allow one to specify the test name/names on the command line?Yup. The way I've been thinking about it runtests will take a list of test methods to run (with handy shortcuts to run all the test methods if you give no arguments, all the methods in a class and its children if you give a class, etc.)
This is nice since you can trivially run one method, or do things like run all test methods with specific "tags" (ala groups in TestNG and friends.), or run whatever other bizzarro test method selection system that you want. The order of the test methods can (if you want) be completely disassociated from the class the method lives in.
Then I can munge it together with some stuff that persists the state of previously run tests so you can run your test suite in "most recently failed test method" order. I've got some very non-portable hacks that do this for me now and, with a sprinkling of POE and Module::Refresh, have a sort of persistent test runner that's like my old testwatch hack on steroids. It's too ugly to be let out into the real world though. I need to clean up runtests and pull out a nice little iterator and I think everything else will fall together quite nicely.
If it wasn't for this pesky work thing
:-)
