KReport/Autotests: Difference between revisions
< KReport
(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 | 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:
- Inserts some elements onto the report sections, save to the .kreport design format, then the markup is compared with the sample
- Opposite direction: load .kreport designs, verify if report elements and their properties are as expected
- 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.
- 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.