Testing reports

[Derek Atkins]

"Colin Scott" <gnucash at double-bars.net> writes:

>> Colin Scott is the one who wanted the output format to be tested.
>
> To nit-pick a little, I was less concerned that the output format (ie,
> the layout) and changed than that the formatting - the characters that
> are included to achieve the layout - had changed.  This is because the
> formatting has implications for how the report renders if imported
> into Excel.  Changes to the layout may or may not be an error, but I
> would view it as problematical werea report changed in such a way that
> the layout (and especially the columnar layout) varies according to
> whther the report is being viewed natively or within Excel
>
>> Better to get the basics covered first before we worry about that. 
>> Unit testing the reports code would be an excellent start. 
>
> Couldn't agree more!  

So basically what you would like to test is that the normalized HTML
output is "the same".  This would require:

a) a test data file fixture
b) a way to run a report and get the HTML output (normalized or not)
b2) a way to normalize said output
c) a stored test fixture to test against, for regressions (potentially)
d) the test itself which manipulates the data file fixture, runs the
report (potentially a second time), and compares the normalized HTML

I don't think we necessarily need to run this in guile, per se.  I'm
pretty sure it's possible to drive this from C.  However I don't know
how hard it is or would be.

> Colin

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available