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

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

On Thursday 27 February 2003 15:01, Erik Enge wrote:
> David Faure <dfaure@trolltech.com> writes:
> 
> > Nope. But it shouldn't be too hard to write a filter that uses
> > kdeprint (and a KoDocument) to print to a koffice document into a .ps
> > file.  Hmm, at the moment the printing code is in the view though,
> > maybe the filter needs to create a hidden view.
> 
> This makes me curious.  How do the developers of wv2 test it then?  Do
> they recompile kword and use it for every change they make?

Hi!

The mail is long, but please read at least the marked part below and send your 
comments :-)

I'm the author and maintainer of wv2. When I want to implement a new feature 
(say, reading table information from the document) I read the paragraph(s) 
about e.g. tables in the MS Word file format specification. This information 
is sometimes incomplete, sometimes outdated, sometimes plain wrong, but over 
the last year I got used to the way the designer of the .doc format thinks. 
Due to that I sometimes find "bugs" in the specification even before I start 
coding.

When I know how e.g. tables work I try to come up with a sane design that 
hides the ugly details and hacks from the public API. Sometimes this is quite 
hard for an "insider"; then David Faure ask me whether I've gone bonkers :-)

After that I write a set of 10-30 test documents (with screenshots), trying to 
exploit all the features of e.g. tables in Word (e.g. first a plain table, 
then one with merged horizontal cells, vertical merging, colors,... you get 
the idea).

Coding the feature is quite simple, most of the time, and after a first draft 
I litter the code with debug statements and run it on the set of test 
documents I created before. If I get unexpected results I return to the spec 
and start over again :-)

When I think that the feature (and especially the public API for the feature) 
is stable enough for a first test, I ask David to add it to the KOffice part 
of the filter (filters/kword/msword). Then I get bug reports from David :-))
Once that's finished we do visual tests using KWord.

######################## Please read the stuff below :-)
I'd really like to implement a way to automatically test documents, but I 
didn't come up with a sensible approach up to now. One idea would be to have 
a fake "consumer" filter, recording the callbacks and all the data and write 
it to some file. Afterwards it would be possible to verify that the file is 
properly parsed by comparing the output.

A different approach would be to use koconverter to generate .kwd files and 
somehow diff the generated XML.

All those approaches have different advantages and disadvantages, and I'd 
really like to get your input on that. Any test engineer around? :-)

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]