On 7/15/06, Ovid <[EMAIL PROTECTED]> wrote:
Just a thought:use Tests qw/ Exception Differences /; Have it import those modules and check for sub conflicts.
This doesn't really buy you anything over: use Test::Exception; use Test::Differences; That already warns on import conflicts. In fact you lose the ability to pass in any import routines. And where do you set the plan?
By default, it would also provide the Test::More tests but it should also normalize sub behavior:
Write Test::More::Normalized or something.
can_ok $proto, $method, $description; isa_ok $instance, $class, $description;
What problem are you trying to solve here? Is the slightly different interface from the rest of Test::More really a problem? They still don't line up with everything else as they're not of the form foo_ok $got, $expected, $description. Is their interface being slightly different a bigger problem than the one you're introducing by changing the interface from how it works everywhere else? The user will now have to remember "can_ok works like *that* except when I'm using Tests in which case it works like *that*". I would suggest instead providing new functions with different names than changing the way the old ones work. It introduces a porting problem. One cannot simply slap "use Tests" at the top of an existing script. Presumably isa_ok()'s $description now becomes free form. What sort of free form $descriptions do you want to put in there? Does isa_ok $obj, $class or diag($description) solve the same problem? Ditto can_ok's lack of a description. Finally, the interfaces are different for a reason. You often want to test a big list of methods with can_ok(). isa_ok() has a pretty narrow range of possible descriptions.
skip $number, $description;
$number is optional when 'no_plan' is on which would lead to things like: skip undef, "foo"; or magic such as: skip $description; skip $number, $description; where skip() guesses what you meant by the contents of the first argument. Yuck.
