[Kde-print-devel] [Bug 140006] Create standard procedures to test KDEPrint (and all components it relies on) for regressions, and KDE applications' interaction with KDEPrint

[Sebastian Sauer]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=140006         




------- Additional Comments From mail dipe org  2007-01-14 12:44 -------
Cause it seems the mail CC to 140006 bugs kde org didn't come through for whatever reason (btw, it never worked for me too and even CC_MAIL:xxxxxx bugs kde org in a commit does not work here), I copy+paste the mail I got from Kurt here cause I guess it may useful for others to read it too;

--------------------

Well, what I have in mind is not so much a single script, but more a
complete set of scriptlets and utilities (as well as howtos and 
tips+tricks snippets and "best practices" articles).

Since I only "speak" Bash (and that not even completely), it will be
started on that level. Some of the better stuff may later even be
ported to other levels. Some of the ideas may sooner or later be
turned into C++/Qt code to go into KDEPrint proper.

The first one I'll tackle is my idea of a "CUPS Cloning"-script.
Hmmm, maybe it is not cloning so much... it will be grabbing the
current CUPS sources from their SVN, building them and start them 
as a separate instance (in user space) on a different port such as
23631. It will serve to test interoperability between CUPS-stable
and CUPS-SVN and can be used as counterpart to test current KDEPrint
code against. 

People will be able to test a lot of functionality without even
owning or having access to a real physical printer.

A few debugging tools will come with it: the ability to take a copy
of the print file on each level of the CUPS processing + filtering
stages: how it arrives, what it looks like after pstops has done
its work, etc. It will have a more sophisticated PDF-printing
backend than the simplistic KDEPrint print-to-file printer, so
that people can better look at some of the results (n-up printing,
image quaility, etc.)

The idea is to then extract from every bug report that is not just 
a simple mis-configuration a little reproducible test case & script 
that can first be used to help debug the problem, and by later be 
at turned into regression test.

Also, all major KDE applications and developers should get a set 
of tests to perform for their printing needs. I don't know how 
much of this can be automated, but I think a good part of it can
be... (see for example what I did with one bug report I processed 
last night: http://bugs.kde.org/show_bug.cgi?id=125150#c4 plus
attachements).

Take KWord for example: from the bugzilla entries (and my own ex-
perience with it) I can clearly see that there are re-curring 
problems seen by users (font rendering on screen, font represen-
tations on paper, font embedding, custome page sizes for export
to PDF and for printing to paper). These observations could be 
transformed into a set of test cases: "Here's the test file; these
are the fonts you need to have installed on your system; these
are the settings to be used to get optimal PDF export (printout)
and here's a script that you have to run to see the result; and
if it finds a problem, it will report it to you." Or: "To test a
new font, use these 3 template files (KWord, OpenOffice, Scribus);
activate the font for them; make screenshots and export to PDF;
compare the 3 results."

Similar test for KSpread, Krita, Karbon, $whatnot... I guess a
lot of these can make good use of Kross also.

Right now I'm working on the "Setup An SVN CUPS Server on port 
23631" script. And on the "Show Me A Better Matching Print Preview"
one (just a working "proof of concept").

I'll let you know any progress.