[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 13:06 -------
So, basicly there are 2 cases;

1. Test KDEPrint itself which is independend of the applications that are using it. This is IM(H)O the most important part since if something here does not work all KDE applications are affected.
2. Concret content an application likes to print. Such tests need to be done for each major application. I would see here a minor priority since I don't really believe that e.g. printing in KWord could break such often. Also KWord 2.0 comes already with testcases that test internals like the text+layout stuff.

So, what I would suggest is, to take one application and implement tests for it to be sure things like layout, fonts, forms and whatever else e.g. a PDF is able to contain got tested. I see there 2 good candidates: KWord and KHTML. Both of them are rich "layout apps" and are able to produce complex enough content to test various cases that could break.
Why it should be quit possible to control both of them (dbus? kross? javascript? or just (k|q)unittest's?) an alternate may to write a small app that does nothing more then to produce some output that goes through KPrinter. The advantage of the later one would be, that such a "testapp" could then test explicit the cases and would be propably smaller + easier to maintain. The advantage to take an already existing app would be, that the app itself then has as result a good unittest for printing plus it may possible to reuse already existing stuff like the KHTML regression-suite or the KWord/OpenDoc unittests.