test cases

[stevegt]

We've already done a bunch of test case cleanup while working #24. I'm worried that some of the stuff we've done so far, not to mention the API refactoring we're talking about in #22 and #16, could silently break or subtly alter the output of one of the examples and we might not catch it.

So @koshchei is right now working on a platform-neutral tool in Go that hashes the output files in the examples. We'd run that on a version from a few days ago before all of the current work started, and it would store the hashes in something like examples/*/.sums.

Every test run after that would re-hash after running the example tests and compare the results with the reference hashes. We'll see how this goes, but I think it could work.

We're looking at storing just the hashes rather than the output files themselves due to the fact that, right now, the .dxf, .stl, .svg, and .png output files together total up to over a gigabyte in size already. ;-)

[deadsy]

Testing a hash of the output files is likely to be fragile. For example, I can think of a single number that if changed would alter all stl outputs. Not in a way that would break them- just in a way that would be a bit different. As a base regression it's not a bad idea, but you'd have to be prepared to resync the hashes as needed.

[stevegt]

The Hausdorff Distance filter mentioned in #31 should be able to provide diffs with tolerance for sdf objects. An end-to-end test would also include an import and diff of rendered STLs, possibly using https://github.com/hschendel/stl for import. STL import would also address #14.

[deadsy]

Using the SHA1SUM files for now.