You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently our testing only accounts for regressions against an existing saved svg. This is very primitive and subject to churn when we change the svg output e.g. to add transforms as in #40. We could add a test-time dependency on an svg processing library such as svgelements to test invariants between current output and reference svgs, rather than testing exact text equality.
I like this bit in their readme about Inkscape-produced svgs:
Since the (oversimplified) input into this tool is SVG that comes out of inkscape, every element/group/layer/etc. will have a unique ID. The task is to parse the XML, match the ids of the elements/groups/layer/yaddayadda in A.svg to the things in B.svg and see if there is a difference. For example, perhaps there is a new layer in B.svg. Maybe some elements in A.svg were grouped and moved to a new layer in B.svg. Perhaps the color or size of an element changes from A.svg to B.svg. The unique ids are the key to determining the differences.
We could do the same thing here, e.g. the g group for a layer (#42) gets the layer name as the id, and elements within that layer get layer_name-index.
Currently our testing only accounts for regressions against an existing saved svg. This is very primitive and subject to churn when we change the svg output e.g. to add transforms as in #40. We could add a test-time dependency on an svg processing library such as svgelements to test invariants between current output and reference svgs, rather than testing exact text equality.
See discussion here.
The text was updated successfully, but these errors were encountered: