| Summary: | app-text/libspectre FEATURES=test doesn't actually test anything | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mart Raudsepp <leio> |
| Component: | New packages | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mart Raudsepp
2011-04-08 01:27:29 UTC
To test need a sensible postscript test file then, and run the tests on it manually after creating result dirs. I tested on a huge xlib.ps file (335 pages) that I found on my machine (probably too big for a good enough test, also only portrait mode pages, no rotation, etc, that is - not a good test), like so: cd test/ mkdir parser-result mkdir spectre-result ./parser-test /home/leio/xlib.ps parser-result ./spectre-test /home/leio/xlib.ps spectre-result parser-test will have various txt files in it. spectre-test should have png renderings of each document page, and some other tests, like PDF result, some sort of reduced page count postscript file, rotated stuff and more. The latter crashes because it has an assert case in it, which is supposed to crash in a release build (the build we want), so need to also patch this line out of test/spectre-test.c: spectre_document_load (NULL, argv[1]); I have no idea if it actually will ever fail though, unless it crashes along the way. It spits out various non-fatal errors for me, but returns with success code. Maybe that's fine and they are errors in the postscript file I use, rather than in the library. Would be nice if upstream would make it more automated. Have results to compare the results of a certain test file to, etc. Tests disabled, as they dont test anything |
