Michael Droettboom wrote:
I've committed support for comparing SVG files using Inkscape and verifying them against the official SVG DTD using xmllint.
Man, are we standards compliant around here or what? Cool.
Michael Droettboom wrote:
Andrew Straw wrote:
Done in r7863. To make use of it, do something like the following patch
(and don't forget to delete the baseline .pdf files from the repository):
-@...782...(baseline_images=['simplify_curve'])
+@image_comparison(baseline_images=['simplify_curve'],extensions=['png'])
Great!
This is a nice feature. However, in hindsight, I may not use it right away -- I actually found a bug in the SVG backend using one of the tests I assumed would only affect the Agg backend.
I think it's good not to use the feature very much. I've already found it handy when developing against a test -- you only need to generate that test's image once.
A couple more comments about the test framework -- which has already paid for itself ten times over. In Numpy (and a number of local Python projects), I can 'cd' to the tests directory and do something like:
nosetests test_simplification.py:test_hatch_simplify
and run on particular test, or a single file of tests. It's a huge time saver when trying to fix a bug. However, with matplotlib I get:
> nosetests test_simplification.py
E
ERROR: Failure: ImportError (cannot import name cbook)
<snip>
I suspect this is something peculiar to how matplotlib gets imported.
Yes, it would be very nice, I absolutely agree. I'm not sure what's going on, either, but I agree that it would be nice to fix. See below for an idea.
Also, I have a quad-core machine, so I put this in my .noserc, which will run tests in parallel:
[nosetests]
processes=4
Unfortunately, due to however matplotlib is delegating to nose, this doesn't seem to get picked up.
I don't know if I'll get a chance to look at these things right away, but thought I'd share in case the solutions are obvious to anyone else (which I know isn't good form, but hey...
My guess is that this may actually be related to the first issue. On this second issue, though, I have a specific idea -- in order for MPL to pickup the nose plugin, I had to do the song and dance in test() of matplotlib/__init__.py in which I create a nose.config.Config instance. I suspect this is why your processes argument isn't getting through -- we're completely bypassing any local nose config and creating ours programattically. I'm definitely not in favor the big song and dance, so if you can rip it out and still get the plugin to load, that would be super.
Once that is figured out, presumably the direct call to "nosetests test_simplification.py:test_hatch_simplify" will also load the nose plugins and thus not exhibit weird behavior when a known failure is encountered.
I almost certainly won't get a chance to look at these right away, so if anyone wants to go spelunking in the nose/mpl interaction, feel free.
-Andrew