Allow additional sub-class flexibility and Moose::Role integrations

[paulsalcido]

Hello Sir,

I have worked with Test::Class a bit in various settings, and I have made changes similar to this in production environments so that Test::Class could be extended a bit more easily. The tests that I've written include some examples of what I mean.

If you could find time to take a look, review and send me some feedback, or even a simple rejection if you don't like this direction, then I would be delighted to make additional changes or keep this fork alive for others if they are interested in this behavior.

Also I was careful to make sure that there is no Moose dependency in the code. It simply skips my tests if someone doesn't have Moose installed. I did have it in there for a couple of commits, but whatever.

I can rebase and force push up if you don't want my intermediate commits.

Thanks for your time!

Paul Salcido

[karenetheridge]

You might want to take a look at Test::Class::Moose, which is much more moosey?

[paulsalcido]

I don't really see why. Test::Class::Moose has fewer capabilities, and these changes would allow for things like Moose roles to be directly applied to Test::Class objects. Plus, it allows for the overriding of behaviors which just wasn't there before. Calling methods as $self->method_name() is superior to method_name($self) because it allows for behaviors to be overridden. In addition, this eliminates a static variable hashing actions by package name, which allows for anonymous class handling and a few other things.

In fact, I think that the changes here would eliminate the need for Test::Class::Moose. It is the behaviors listed that don't allow for true OO behaviors in this package. I really think that they should be looked at and considered, regardless of the existence of other packages trying to solve the same problem.

[karenetheridge]

It may well be that your changes overlap with what's in Test::Class::Moose, but the fact remains that that distribution is undergoing active development, whereas Test::Class isn't -- so I think you'll have more luck getting your features added there than here.

I'd even welcome @Ovid taking over Test::Class and merging it with Test::Class::Moose, although that's not my decision to make.

[paulsalcido]

Meh, I'll keep it up, if someone likes it, they can use it. Perhaps I'll keep it up to date with Test::Class in the future. I did this to aid someone else and thought it might be helpful.

[Ovid]

@paulsalcido wrote:

Test::Class::Moose has fewer capabilities

I'm sorry, but this really confuses me because as a long-time Test::Class user, this statement appears to be incorrect. Could you please state what capabilities that Test::Class has that Test::Class::Moose does not Unless I've missed something (I confess that I've only skimmed the code) Test::Class::Moose supports the features you're suggesting here, and much more, and more improvements are coming from a branch Dave Rolsky is working on, including reporting, improved (and out of the box) parallelization, native control over how test methods and classes are run, parameterized roles, and so on. You're not getting that in Test::Class any time soon.

Further, the author of Test::Class recently stated that he's doing no Perl work at this time and was looking for another maintainer (possibly me). He's not going to be updating Test::Class. Though the changes you suggest look nice, I'm not sure they're going to be adopted here.

[adrianh]

Yeah - what Curtis said ;-) Last time I looked T:C:M has a superset of T:C functionality - not a subset.

(Also - Curtis - taaaaaaake iiiiiiiit ooooooover ;-)

[paulsalcido]

OK, I'm not sure if that was true when I wrote this pull request, and even then it could have been a misunderstanding with some of the people that I was working with, requesting this change.

I maintain my indifference.