Inkscape 1.0 roadmap goal - test writing
Hi all,
A priority for the 1.0 release is working on improving our testsuite. At the last hackfest, it was asked that the individual tasks be broken down and divvied out to people so we can distribute the work.
Below, I've broken out the work as best I can and have proposed owners for each task. If you can't do a task, or would like to take on additional ones let me know.
1. Migrate the old test cases to GTest Refer to Tav's b50500c7 as an example of how to convert.
Alexander Valavanis, would you be able to convert these two? + extract-uri-test.h + uri-test.h
Tavmjong Bah, mind doing these? + mod360-test.h + preferences-test.h
Adrian Boguszewski, would you be available to do these two? + object-test.h + sp-gradient-test.h
Eduard Braun, could you try these two? + marker-test.h + sp-style-elem-test.h
2. Establish a regression SVG file collection
I forget when exactly we discussed this, but the idea was to have a place to easily collect random SVG files from bug reports or community members that exhibit odd behaviors or provide stressful workloads for performance testing.
The best way to structure this, I'm not sure. Probably keep them separate from the main codebase, maybe with laxer commit permissions?
Marc Jeanmougin, you've been doing a lot of good work lately on setting up testing, including some render check testing in the main codebase. Would you be willing to take ownership of this task?
3. Implement new unit tests.
We need additional GTests to cover a number of areas of the codebase. These need added in testfiles/src/, see the other tests there for examples.
Who'd like to volunteer to work on these?
* SP objects * verbs * cmdline options * UI widgets/tools * UI view * UI dialogs * live effects * etc.
Bryce
Establish a regression SVG file collection
I forget when exactly we discussed this, but the idea was to have a place to easily collect random SVG files from bug reports or community members that exhibit odd behaviors or provide stressful workloads for performance testing.
The best way to structure this, I'm not sure. Probably keep them separate from the main codebase, maybe with laxer commit permissions?
Currently it's in the main codebase so that it can be run with "make test" at each commit/MR. It can be easily moved to a separate repo when we will use git submodule
Marc Jeanmougin, you've been doing a lot of good work lately on setting up testing, including some render check testing in the main codebase. Would you be willing to take ownership of this task?
Sure ! I even recently discovered we used to have such a suite (in 2014) : https://bazaar.launchpad.net/~inkscape.dev/inkscape-rendertest/trunk/files
Another related thing I started a while ago and will finish One Day(tm) (probably when there will be an easily compilable gui-less inkscape with no gtk) will be to integrate Inkscape into a fuzzing engine to automatically find files that would crash Inkscape on launch.
participants (2)
-
Bryce Harrington
-
Marc Jeanmougin