Re: [Perlunit-devel] Teensy PerlUnit suggestion, and a question
Status: Beta
Brought to you by:
mca1001
From: Matthias F. <mf...@hi...> - 2002-03-18 18:26:56
|
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. 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? Thanks, Matthias On Mon, 18 Mar 2002, Adam Spiers wrote: > Matthias Ferber (mf...@hi...) wrote: > > Er, question first, shall we? I wonder if you have a recommendation for > > how to approach the problem I'm trying to solve, given PerlUnit's current > > architecture. I want to be able to start a TestRunner running against a > > dynamically generated suite, where the suite itself is determined by the > > command line. > > > > So, for instance, I imagine the command line looking something like this: > > > > perl TestRunner.pl MyTestMaker arg1 arg2.... > > > > where MyTestMaker has a suite() method that uses the arguments to generate > > the appropriate test suite. The thing is, there's no way for MyTestMaker > > to get access to the arguments, because they're all eaten up by TestRunner > > and not passed along. Is there another way (a "right" way) to do this? > > > > My solution so far is to bypass TestRunner.pl, instead using a script that > > generates the test suite, creates a new TestRunner object and starts it > > running with the constructed suite. The two things I don't like about > > this are that it relies on the TestRunner::do_run() method, which I'm not > > sure is a public part of the API, and that I'd rather use TestRunner.pl if > > at all possible. Any suggestions? > > I think you've done the right thing (in the context of the current > PerlUnit tree, at least), and that do_run() should be part of the > public API. If you wanted to extend the argument syntax of > TestRunner.pl to allow parameters to be passed to tests, feel free to > post a proposed syntax here. > > It looks like this part of PerlUnit needs a bit of a spring-clean; for > instance, I can't see anything that uses TestRunner::run() or > TestRunner::run_and_wait(). I'll add this to the TODO list. > > > OK, now my own small suggestion. I was confused at first when a Boolean > > assertion failed with the message "Expected TRUE, got FALSE." Seems to me > > that a Boolean test doesn't have an expected value the way an equality > > assertion does; how about changing the message to "Assertion failed"? > > I've changed it to "Boolean assertion failed". > > -- > Adam Spiers -=- musician & hacker -- ad...@sp... -=- http://tigerpig.org/ > $_=q{*{$Just =bless{},'$another ';"\$Perl \::$hacker"}=sub{print$%[$.++];$,,$ > ;$_[0]},eval join+v45.62,('$z')x6};s/(?<=\$)([a-z\n]+ ?)/push@%,$+;f/egi;eval > > _______________________________________________ > Perlunit-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perlunit-devel > |