# from Andy Armstrong # on Wednesday 31 October 2007 16:51: >But what about a more general mechanism? A TAP directive that means >'schedule these other tests'. So then you'd have a controller test >which was the only one directly visible to Test::Harness and that'd >decide which other tests to run.
It sounds like it would be re-creating a lot of the same functionality needed for declarative extra testing and/or Test::Manifest. http://scratchcomputing.com/tmp/extra_testing.txt I would rather it not be a TAP directive. Yes, it abstracts the "manifesting" into TAP, but it still requires some code to run to determine the manifest, and will therefore be less introspectable. Further, I've never really seen the point of the "controller test" pattern. It has always seemed like a workaround for a lack of harness features or something. Anyone got a better explanation? Yes, there are limitations to a 100% declarative scheme, but it has the advantage that 90% of usage becomes introspectable. Probably another 9% could be covered with a few "canned methods" -- which bottle-up some procedural code into standard phrases (ergo: introspectable.) The remaining 1% can be handled by an "eval this" entry (which could at least be sandboxed.) --Eric -- "It is a mistake to allow any mechanical object to realize that you are in a hurry." --Ralph's Observation --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
