wishlist - test harness
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
New
|
Wishlist
|
Unassigned |
Bug Description
Wishlist
Inkscape is way past the point where it should have a complete test harness so that bug fixes and new code can be thoroughly tested for side effects before they are committed. Since the program runs off a GUI this is likely to be fairly difficult to do, especially since, as far as I can tell inkscape does not have a central event queue structure (maybe one of the GUI libraries it uses does?). Assuming this is actually possible, for quality control purposes it would probably suffice to have a "macro" like facility such that one would start the program with something like:
inkscape --record=
perform a series of operations through the GUI and exit. Then to (re)run the actual test:
inkscape --play=test123.txt
followed by diff on the various file or files produced to see if the test passed.
As a specific example, I have recently been working on EMF input and output, and can imagine the automated test control program (using one of the existing such systems, no need to reinvent the wheel) might offer a complete series of tests, but
could also be limited to certain tests. So that I could test (just) my EMF work with something like:
[x] EMF input
[x] EMF output
[ ] everything else
Then, before a commit, enable all tests (to catch unexpected interactions) and run that. Whenever a new feature is added, or a set of commands is found to do something which requires a bug fix, the contributor of the feature/fix would also write a corresponding test case. Additionally, for a really thorough workout, at least on Linux, there would be an option in the test harness to run all of the tests within valgrind, to catch latent memory access problems (those not causing an immediate crash or error in output.)
Note that there are already some tests available (see http:// wiki.inkscape. org/wiki/ index.php/ Testing_ Inkscape).