KReport/Autotests: Difference between revisions

From KDE Community Wiki
(Created page with "We use ther ''autotests'' term because these are not always just unit tests but also functional. All stored in SRC/autotests/ (subdirs). Data for given group of tests stored...")
 
No edit summary
 
Line 1: Line 1:
We use ther ''autotests'' term because these are not always just unit tests but also functional.
We use the ''autotests'' term because these are not always just unit tests but also functional.


All stored in SRC/autotests/ (subdirs).
==Location==
 
*All stored in SRC/autotests/ (subdirs).
Data for given group of tests stored in a data subdir.
*Data for given group of tests stored in a data subdir.


==The .kreport format==
==The .kreport format==

Latest revision as of 09:16, 29 July 2015

We use the autotests term because these are not always just unit tests but also functional.

Location

  • All stored in SRC/autotests/ (subdirs).
  • Data for given group of tests stored in a data subdir.

The .kreport format

Code stored in SRC/autotests/format. Data in SRC/autotests/format/data.

Types of tests identified:

  1. Inserts some elements onto the report sections, save to the .kreport design format, then the markup is compared with the sample
  2. Opposite direction: load .kreport designs, verify if report elements and their properties are as expected
  3. Roundtrip: load the .kreport designs, save back immediately, compare with the original


Special:

  • Collect .kreport samples for test cases for legacy elements/formats, use above tests with them
    • Example: the field element

Writers

For KReportWriter implementations.

  1. Load a sample, load some data, write using a KReportWriter, verify the result

Scripting

Kexi 2.x Reports offered some limited scripting. The task is to collect all supported cases for that in a form of .kreport samples. Testing can be identical to the Writers autotests explained above.