[qmtest] algorithms with less storage for producing results.xml?

[Nathaniel Smith]

On Thu, Aug 17, 2006 at 11:45:37AM -0400, Allyn Dimock wrote:
> [ This had not been an issue for us when using qmtest 2.0: the xml report
> not being availble at the time, we reverse engineered the results.qmt
> format to generate the reports that we wanted in one pass per report (one 
> summary report that was e-mailed to developers and detais were in a 
> collection of html files referencable from the rt ticket tracker system).
>   In 2.3 we started relying on results.xml since the results.qmt format 
> had changed from 2.0 and we did not want to reverse engineer multiple 
> times when a non-proprietary format was available. ]

Note also that no reverse-engineering is required -- you can write an
implementation of qm.test.result_stream.ResultStream that does
whatever reporting you like.  This can then be plugged into qmtest
(using the standard qmtest plugin machinery, whose details I no
longer remember) to process results directly while 'qmtest run' is
running. or after-the-fact -- 'qmtest summarize' can read results out
of a .qmt file and feed the results into your reporting class.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco