On Tue, Mar 08, 2005 at 11:24:59AM -0800, chromatic wrote: > > chromatic, do you still have those notes? > > Hm, not anywhere close. I think they were on your laptop, the one you > took apart at the last TPC in San Diego.
Then it may be gone as Apple ate my last hard drive. It possible I have an old backup lying around or even that old hard drive from my last Mac. I'll look. > Test::Builder - the primary interface. Not a singleton anymore. Test > modules create new instances and tell it the default level. This > removes a global variable. > > Test::Builder::Output - a singleton contained within Test::Builder. > This holds the output filehandles. > > Test::Builder::TestRun - a singleton contained within Test::Builder. > This holds the plan, the counter, and the test details. > > Test::Builder::Counter - a singleton contained within > Test::Builder::TestRun. This counts the tests. Good, I think these are the obvious features that must be in common across all modules in a process. > Test::Builder::TestResults - the parent class for all types of tests > (pass, fail, todo, skip). This may be too much detail here, but I like > the idea of these knowing how to format themselves for output. Dunno what this is for. > By default, everything looks the same to using modules, except that the > level trickery can go away, mostly. It should be easy to swap out > TestRun and Counter and TestResults within the current Test::Builder > object temporarily, in the case of wanting to run a lot of subtests > without increasing the number, for example. So how does it handle these scenarios. * Testing a test module. * Altering the behavior across all modules used in the process. * Altering the behavior for just one module.
