Jerry D. Hedden wrote: > From what I can tell, there are well over a dozen > dual-lived modules that incorporate test.pl into their > distributions. Rather than continuing this trend, I would > like to propose turning it into a module and dual-lifing > it to CPAN.
Nicholas Clark wrote: > Why are they using it, rather than something built from > Test::Builder? What does it offer that Test::Builder > derived modules don't? Jerry D. Hedden wrote: > In my case of dual-lifing threads, threads::shared, > Thread::Queue and Thread::Semaphore, it was because the > tests were already written to use test.pl. Thus, adding > it to the distribution was easier than rewriting all the > tests. Nicholas Clark wrote: > But, logically, those tests in the modules in core can be > re-written to not use it [if, see below] Jerry D. Hedden wrote: > I would imagine that is also the case for the other > dual-lived modules that use test.pl, but their maintainers > could have other reasons. Anybody? > > Additionally, test.pl has certain functionality (e.g., > fresh_perl() and watchdog()) not found in the Test::* > modules. Nicholas Clark wrote: > hence I think that a better solution would be to add just > that code to a Test::Builder based module, either a new > one, or an existing one if its maintainer is keen. > > The core's test.pl is meant to be a subset of the > Test::More functionality for core regression tests in t/* > (distinct from tests in lib/* for modules shipped with > core). To me it feels like scope creep if it also ends up > dual-lived. It also means that we would have *two* > core-supported test frameworks, which can't be used in the > same test. If the functionality in test.pl (that does not currently exist in other module) could be duplicated elsewhere using a Test::Builder-based module, would there be a reason then to maintain test.pl? Would it be better then to eliminate test.pl entirely?
