[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: wv2 testing (was: Re: wv2 command-line interface.)
From:       Werner Trobin <trobin () kde ! org>
Date:       2003-03-01 21:10:01
[Download RAW message or body]

On Saturday 01 March 2003 19:14, shaheed wrote:
> On Friday 28 Feb 2003 6:36 am, Werner Trobin wrote:
> > - It loses some of the data (because KWord doesn't use the whole CHP and 
so
> > on). This doesn't trigger bugs in KWord, but might still be a regression 
in
> > wv2.
> 
> Yes, as a test of wv2, you are right. Could you output the extra stuff in a 
> comment - assuming koconverter allows that? KWord would obviously not. Its 
at 
> least readable that way....and David can see what is "missing" in KWord :-).

There are a lot of fields in a CHP which will never be used in KWord, because 
the concepts don't match, the fields are obsolete, or undocumented. The 
generated code contains methods to dump a struct like a CHP or a PAP to a 
string (a bit like key=value pairs, one line per variable). A fake consumer 
filter could just dump that information, without working around koconverter 
or adding hacks to KWord files generated by the filter.
 
> > - It's not trivial to update the reference documents when you implement a
> > new feature (or KWord changes its file format).
> 
> Tell me about it!

Imagine you implement support for images. Right now wv2 skips "special 
characters" indicating images, but as soon as this feature gets implemented 
it will trigger some callback and deliver information about the image. This 
extra information will show up in the test-output and the diff reports a 
false positive. Then you manually have to compare, check, and record all the 
reference files again. If you know a way how to automate that (or at least 
make it pretty painless) I'd be highly interested to discuss that :-)

> > Of course it's better than no testing at all (or visual testing of 10
> > documents instead of the whole test set of 150 or so).
> 
> Yes, especially if you can use koconverter then you can run the diffs 
> overnight...no DCOP needed.

Overnight... hmm, the filter takes about 0.4 seconds on a fairly complex 
30-pages document with lots of tables, and diffing a file with several 
thousand lines shouldn't be that expensive. I'd estimate it would take less 
than half an hour on my current set of test documents.

Ciao,
Werner
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]