On 7/3/05, Michael G Schwern <[EMAIL PROTECTED]> wrote: > On Sun, Jul 03, 2005 at 09:10:51AM +0200, demerphq wrote: > > Ive been putting together a Test:: module to handle the kind of deep > > comparison that I think is_deeply should do. Ive noticed some minor > > issues with the process. > > Thank you. I get very little feedback in this regard and appreciate it.
No problem. Glad its helpful. > Many moons ago (about 36 moons) I wrote this talk which is about all there is > on the subject. > http://www.pobox.com/~schwern/talks/Writing_A_Test_Library/ > > Let me know if it helps. Yeah actually its a good step. One thing that would have been helpful would be a small section in Test::Builder about how in general Test:: authors are probably going to be writing specialized tools, in which case they should be expecting their users to be using some other general purpose testing tool as well. Part of the confusion I think is the synopsis with the import. That implies that Test:: modules should stand alone as well as mix in, which i guess lead me to get my metaphors mixed up. > > Another issue I had is that its not particularly clear what the deal > > is with an import method per package. Why is it necessary to recode > > (slightly differently everywhere) the import routine? I personally > > would have found it much nicer to say > > > > @ISA=qw(Test::Builder::Extension); > > > > and then have the import malarky automatically included. > > http://rt.cpan.org/NoAuth/Bug.html?id=8656 > > I was just thinking about that today. Cool. That would be nice. It would make writing a new Test:: module much more plug and play. > > > Another issue i had was that its quite difficult to extend and > > override Test::More. > > You're right, that's because you're not supposed to. You write your own > module using Test::Builder and let the user use it in conjunction with > Test::More if they want. I prefer this greatly to everyone writing their > own "Test::More with stuff" module because not only does it violate the > "small sharp tool" philosophy but then you run into the problem of having > "Test::More with X" and "Test::More with Y"... what happens when you > want X and Y? A big import clash, that's what. And thats fine pretty much, but since it wasn't spelled out what the recommended approach was I wasnt sure what the Right Thing To Do was. As I said some tips along this line in the Test::Builder docs would keep people pointed in the right design direction. The whole import thing really made me unsure of my natural inclinations. If the module is intended to be used in conjunction with a GP test module like T::M or T::S why should it even care about handling plan semantics at all? > > I see from the code in your scratchpad that this is exactly what you're > trying to do, export all of Test::More plus your one function. Don't do > that. Let the user load Test::More separately if they want it. > > use Test::More tests => 4; > use Test::Struct; > > will work just fine as long as you don't get in its way. Now that i understand whats happening Im happy to do it that way. I admit also contemplated passing through some of T::M's stuff if the import included the plan component. But i think ill leave it. > > Something that is planned is the ability to change out the default > Test::Builder object as well as moving yet more functionality out of > Test::More and into Test::Builder. > http://rt.cpan.org/NoAuth/Bug.html?id=8379 > http://rt.cpan.org/NoAuth/Bug.html?id=8630 I think thats a good idea. But then does that mean that implementors should actually be inheriting from Test::Builder so that their routines are also available through the back end in addition to providing easy to use subs for export? > > > If I want to write a test package that behaves > > exactly as Test::More except that a few subs do things differently you > > have to go through some interesting contortions to do so. Expecting > > the user to mix and match isnt ideal as if you want to override a > > modules default exports you end up forcing the test author to write > > explicit import lists. Which IMO is sufficiently annoying that id > > prefer not to expect it or have it expected of me. > > Yeah, I've run into this with Test::Legacy but that's a bit of a special > case where I'm working with an existing interface (ie. they both have ok() > functions). In the general case its probably better that you simply not > name your funciton the same thing as Test::More's. Especially if it does > not do the same thing. > > What sort of changes did you have in mind? Well at a certain point the snarky part of my personality wanted to make a Test::Better with an is_deeply() that wasn't broken. But i got over the idea pretty quickly. *g* I guess you can file that in the "wanted to do something he shouldnt have wanted to do, easily cured by a bit of design guidance in the T::B docs" filing cabinet. (Ie the round one :-) > Did you spot any more? Nope. Now that ive read your slides and seen a bit of the feedback here im more comfortable with the way certain design decisions are going so hopefully i shouldnt have more. If i do tho ill let you know. yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
