I was playfully suggesting that behind simply as an abstraction of what
Test::Builder and Test::Harness provide. No way would I inflict that on
an end-user!
David
Ofer Nave wrote:
David Golden wrote:
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.
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...
-ofer
