[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tsp-devel] A document generator for DTest
From: |
Thomas Decherf |
Subject: |
Re: [Tsp-devel] A document generator for DTest |
Date: |
Tue, 22 Apr 2008 10:12:17 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080227) |
Eric Noulard wrote:
I would rather rename your
"DocumentGenerator" class to "TraceHandler" class
and the "DocumentManager" to "TraceManager".
Ok.
In fact I think the "document report" of the test sequence should be seen as
a particular trace generated from the sequence itself.
And in fact if I understand your objectives well the
TraceManager may either be "merged" with
"DTestMaster" itself or became a "member".
Then each DTester will call DTestMaster.traceManager.xxxxx()
for each step they are currently running.
I think DocumentGenerator/DocumentManager follow
the same pattern as DTester/DTestMaster.
I would modify DocumentGenerator/TraceHandler with the following:
0) add addDTester : which will indicate the trace handler
that the specified dtester is involved in the distributed test
sequence.
1) add initialize() method which may be used to build
the header of the report which may indicates
the list of dtesters involved in the test (with their name and location)
the number of planned steps.
Yes, an initialize() method is necessary.
2) I think save(String) should not be visible since finalize() is fine.
You may
docs.registerDocument(HTMLGenerator("/path/to/file"))
then
docs.finalize() will do the ,job.
Yes, definitely!
I think it's better since if you registered several "file oriented"
traceHandler the following
docs.save("/path/file_name")
will need some per-handler name mangling scheme in order
to handle the latex, HTML, TAP, ... several file name need.
Concerning
AppendTest
and
AppendTestStep
I would rather go for
testTitle
and
testStepResult
A documentTitle() method or documentTitle parameter in the TraceHandler
constructor would also be necessary.
When rereading your proposal as a whole I would say that I may have missed
something important.
Do you want to be able to generate:
A) one report for a single DTest sequence
B) one report for SEVERAL DTest sequences?
In fact we need to generate a report for a test campain, which implies
many DTest sequences,
one dtestmasters for each test would be convenient.
I had A) in mind but I now realize that B) may be more useful.
I you target is B) then an autonomous
TraceManager class is definitely needed.
moreover I would rather replace testTitle with
addTestSequence(testTitle,testSummary,dtestmaster1)
the DTestMaster (dtestmaster1) passed as parameter represent
a "single" dtest sequence.
then initialize() and finalize() are not enough.
we need
initializeSequence() and finalizeSequence()
which will do what is needed for each dtest sequence
i.e. each DTestMaster.startTestSequence()/myDTestMaster.waitTestSequenceEnd()
Here comes a possible sequence:
traceManager = dtest.TraceManager()
traceManager.register(HTMLTraceHandler("myreport.html")
traceManager.register(LatexTraceHandler("myreport.tex")
<DTester tester1, tester2 defines their sequence>
...
dtestmaster1 = dtest.DTestMaster()
dtestmaster1.register(tester1)
dtestmaster1.register(tester2)
traceManager.addTestSequence("Test 1", "A complex distributed test",
dtestmaster1)
dtestmaster1.startTestSequence()
dtestmaster1.waitTestSequenceEnd()
<DTester tester3, tester4 defines their sequence>
...
dtestmaster2 = dtest.DTestMaster()
dtestmaster2.register(tester3)
dtestmaster2.register(tester4)
traceManager.addTestSequence("Test 2", "A really complex distributed
test",dtestmaster2)
dtestmaster2.startTestSequence()
dtestmaster2.waitTestSequenceEnd()
...
# here we "finalize" every registered TraceHandler.
traceManager.finalize()
using this scheme each DTestMaster used in a "addTestSequence"
will call TraceManager.initializeSequence() when
DTestMaster.startTestSequence()
is called (same for TraceManager.finalizeSequence()/waitTestSequenceEnd())
during the sequence each DTester registered in the DTestMaster will
call the DTestMaster.traceManager.testStepResult() with appropriate
arguments build from ANY step (ok, barrier, etc...)
DTestMaster may have a "default" TraceManager built-in which includes
a TAPTraceHandler and/or nothing at all.
in fact we may reverse the call to:
traceManager.addTestSequence("Test 2", "A really complex distributed
test",dtestmaster2)
into:
dtestmaster2.registerTraceManager(traceManager,"Test 2", "A really
complex distributed test")
Lots of good proposals in there, the
DTestMaster.registerTraceManager(...) thing seems practical.
My mail is already too long but I think I've layed out my ideas :=)
I'm waiting for you remark too.
May be next time we may exchange python code for
dtest.TraceManager
and
dtest.TraceHandler (an interface-like one would be enough for specs)
Ok, good. Thanks a lot for your remarks.
Regards,
Thomas