Well, upon uploading the first version of Test::Shlomif::Harness to CPAN, I had to pick a good name for it. I brainstormed with people on Freenode's #perl channel, and eventually thought about something like Test::RunTests. Then I checked if there was already a module named "Test::Run" and guess what - there wasn't!
As a result, Test-Run is the new name and it is now on CPAN. Test::Run itself is just an API, and is not meant to be called from the command line directly (for prove or for "make test"). To do that, I also started to work on Test-Run-CmdLine.
Finally, to achieve the summary line in colour (which if you recall was my original motivation for this hacktivity), I wrote Test-Run-CmdLine-Drivers-ColorSummary. The latter is now functional and actually works. It weights in at 27 lines (excluding comments and POD), but part of it is quite sub-optimal at the moment, and may be implemented better with some refactoring of Test::Run.
Now for some issues:
I couldn't figure out how to set tags for the image I posted to Flickr. I thought I have set tags when I uploaded it, but they weren't being set and the image does not appear on a lookup of the "perl" tag.
I discovered Test::Harness' tests have not tested for the correct output (even the most elementary stuff like "All tests successful"). After my refactoring broke some stuff, I had to add some tests like that on my own. I submitted the extra tests, and talked with Andy about it in AIM, but he said that he'd rather not add these, because the output itself is "getting redone".
If you ask me, I think a test coverage should still cover these things, and be modified for the new behaviour when it is changed. This is so they'll have full coverage, and bugs that change the behaviour won't be introduced, when working or refactoring a code. Working on Test::Run has made me realise that refactoring without good test coverage can be dangerous.
At the moment, Test::Run itself depends on Class::Accessor. Is it a bad thing? Should a module like Test::Run that aims to be in the core eventually, have no dependencies except those that are distributed in perl?
On the other hand, I can lobby for the inclusion of Class::Accessor into the core. In my humble opinion, it's high time that it was included.
While I've been thinking that as far as code quality is concerned Test::Run is in pretty good shape, (much more so in comparison to Test::Harness), I often discover a piece of code there that just cries "refactor me". It is usually a function that's just too long for its own good. So I end up refactoring it. But I still appreciate the fact that I started from a working code.
Reading Parameters from the command line and from %ENV is generally something
I'd like to keep out of Test::Run::Obj itself. That's because I want its entire
behaviour to be controllable from its API. Now, the problem is that I'd like
to people to be able to write sub-classes of Test::Run::Obj that will enhance
and customise it. But these classes may have their own necessary customisations
from the environment or command line. (e.g: the
So the million Dollars question is whether the sub-classes should handle the CmdLine/Env handling themselves? Probably not, because a programmer may wish to control them too, from their API.
Right now I'm leaning on both sub-classing Test::Run::Obj and sub-classing an appropriate command line front-end object. The front-end sub-class will pass the arguments to the Test::Run::Obj sub-class. And there will probably be a thin wrapper module that just invokes the appropriate sub-classed front-end.
"Documentation? We don't need no stinkin' documentation!" Or at least we don't need an up-to-date documentation. At the moment, most of the documentation of Test::Run was preserved almost verbatim from that of Test::Harness and was not updated to reflect the newer changes. It needs to be updated.
Naturally, if someone writes one enhancement to Test::Run::Obj as a sub-class, and someone (else or the same) writes another one, why the two of them shouldn't be combined? This probably calls for plug-ins like I saw in Catalyst. This may mean we'll have to use Module::Pluggable and also the NEXT:: meta-class. I don't remember at which major perl 5 version it was introduced, but in this case, it may mean some enhancements will not be available in some older perls.
Finally, how you can help: first of all you can submit patches to the documentation to update it to the newer code. Or write new documentation for all them method extractions. Also, if you feel like refactoring one of the places which is still quite hairy - go for it. You can find the code in the Subversion repository. A few patches like that and you'll become a commiter.
A second thing you can do is suggest ways in which you'd like to see Test::Run (or Test::Harness) enhanced or customised. You can create drivers now, but they may become broken even in the not-so-far future, as I didn't settle on the API and the Subclassing API yet.
And last, but not least, if you find my effort noteworthy, please consider donating. The more money I receive by donations, the more financially-worthy it would be for me to work on Test-Run. If you make a donation drop me a note saying why you did it, so I can try to invest some more time on that particular cause.