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. > Writing test modules isn't well explained. The pointers to look at > other modules are IMO not too helpful. You have to spend quite a while > working out and reassuring yourself of various issues before you are > comfortable with what is going on. A tutorial explaining the general > framwork and the principles behind extending it would be useful. 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. > Just as Nik Clayton wrote its not so straight forward to write tests > of the tests. Test::Simple comes with a framework but its not > installed (?!). What framework is this? Oh, you mean Test::Simple::Catch? Its not really suitable for release. In fact the way I test Test::More is far inferior to things like Test::Builder::Tester. Using the TBT approach would have saved me from having to rejigger a whole bunch of tests because of cosmetic changes to the failure diagnostics. Anyhow, TBT and TT should at least be mentioned. http://rt.cpan.org/NoAuth/Bug.html?id=13516 > 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. > 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. 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. 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 > 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? > Also in places in Test::More there is behaviour contingent on file > scoped lexicals. Specifically in Test::More::diag() there is the > following test: > return unless $Show_Diag; > since $Show_Diag is private it means you have to use Test::More's diag > routine to play nicely with its behaviour. I guess an option would be > to put this behaviour in Test::Builder's plan method or something. > (the 'no_diag' keyword that Test::More::plan() supports). Whoops. http://rt.cpan.org/NoAuth/Bug.html?id=13515 Did you spot any more? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- "Witches Abroad" by Terry Prachett
