Re: [Perlunit-devel] Teensy PerlUnit suggestion, and a question

[Matthias F. <mf...@hi...>]

I built a script that did something like this for JUnit in Java -- the
part about controlling which test methods get run, that is, not the part
about passing arguments, which may be impossible in Java anyway.  I used
colons as a delimiter:

java TestRunner class1:test1 class2:test2...

The colon would be awkward in Perl because it's also used in the class
delimiter, but another symbol could work:

perl TestRunner.pl My::Class1.method1 My::Class2.method2

You could extend that to passing arguments, except then you have trouble
if the argument contains a period (or whatever delimiter).

This isn't a wholly thought out idea yet, but what I like about it versus
passing the method names as arguments is that it can be combined with
passing real arguments.  I'm not sure that holds water yet, though, and
the method-names-as-arguments idea has the great advantage of being
intuitive (perhaps except for the --, but that doesn't seem so bad to
me).  I'm going to try to come up with more ideas and bat this around a
little more.

Here's one off the cuff:

perl TestRunner.pl -switches My::ClassA -m method1 -m method2 My::ClassB

to test two methods from ClassA and all of ClassB.

still thinking...
Matthias


On Thu, 20 Jun 2002, Adam Spiers wrote:

> Matthias Ferber (mf...@hi...) wrote:
> > Thanks for the help, Adam, that's reassuring.  I'm not actually sure
> > whether the syntax I showed as an example would be the best interpretation
> > in practice, actually.  Right now, if I'm reading the code right,
> > TestRunner::start() ignores all but the last argument (not counting
> > switches).  I can see two reasonable ways to change that: one is to take
> > the first non-switch argument as the name of the class to build a suite
> > from and pass the remaining arguments to its constructor, which would
> > handle the situation I'm working on and would look like my example; the
> > other thing it could do is interpret all the arguments as separate test
> > classes, and build a suite combining the suites from each of those
> > classes. 
> > 
> > I like the first idea because it adds flexibility in situations like mine,
> > but the second is perhaps more intuitive and maybe even more useful most
> > of the time.  So I think I'll just throw these both out as possibilities
> > for thought and let 'em fall where they may.
> 
> I've been wanting more control from the command-line recently too,
> which has been a good reason to get off my butt and reply to your mail.
> More specifically, I want to be able to control which test methods in
> a suite get run by passing them as arguments.  The immediate problem
> for me is that I have an equivalent of TestRunner.pl which allows
> running of several suites at once, e.g.
> 
>   $ ./MyTestRunner.pl MySuite1 MySuite2
> 
> but allowing arguments to a suite would break that.  One approach I
> thought of was using '--' to delimit the tests:
> 
>   $ ./TestRunner.pl --switch MyTest1 arg1a arg1b -- MyTest2 arg2a arg2b
> 
> How does that sound?
> 
> It occurs to me that I should probably merge all my runner's
> enhancements back into TestRunner.pl; the latter is a rather lame
> piece of code as it stands.
> 
> > Re TestRunner.pm, if you're going to clean up that part of the code
> > anyway, and if do_run()  is going to be public, may I suggest naming it
> > run_suite() instead for clarity? 
> 
> Good idea; added to doc/TODO.
> 
> 
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
>