David Golden wrote:
That's too much work. If I only have a few questions for my module, can I just use the simpler Quiz::* system? Especially for quick one-off tests...
Just to be playful with concepts:
* Test::Answer -- holds the details of a particular test (pass/fail/skip/todo)
* Test::Scoresheet -- holds a collection of Test::Answers
* Test::Booklet -- sets up a default Test::ScoreSheet object to hold results, creates and maintains new ones as requested and manages an "active" ScoreSheet for recording Answers. On exit, serializes all Scoresheets. The serialization method is abstract and subclasses must implement particular protocols with helper modules (e.g. Test::Protocol::TAP).
* Test::Proctor -- fires up a test script with a particular subclass of Test::Booklet (e.g. Test::Booklet::TAP) and records the response. (perl -MTest::Booklet::TAP test.t)
* Test::ReportCard -- parses results received from Test::Proctor. Subclasses parse particular protocols with helper modules and produce a human/machine readable report. Sub-subclasses could offer alternate report formats.
(Ideally, we'd even abstract the channel in there so we could do it in a way other than stdout).
IMO, the more we can keep these functions uncoupled and generic the better -- and we can let specific implementations provide the details. It certainly sounds like chromatic and Michael have got things headed in the right direction and I look forward to seeing what we wind up with.
-ofer
