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.
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. 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 (?!). From the thread Nik started i now know that there are other tools available on CPAN to do this, but I wouldnt have if it werent for that thread. An explanation of how to test a Test module should accompany Test::Builder as its not straight forward at all. 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. This would also guarantee that a standardized interface to all of the test modules. As it is it looks like the expectation is that each author hand rolls the import, greatly increasing the chance that different interfaces are exposed. Even if there is some technical reason why a standardized import can't be used it would be a good thing to have Test::Builder include a method which could be used to correctly filter out the "plan" part of an import list. If new plan semantics are added then only this routine need be altered to give all consumers awareness of the new stuff. Something like: my (@plan,@import); $Test->extract_plan([EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]); Another issue i had was that its quite difficult to extend and override Test::More. 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. 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). Anyway, maybe ive gotten this all muddled and these arent issues people should worry about for some good reason or another. If so all the more reason for a tutorial. :-) Cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
