The incredible, fallible symmetric Unit Test, and the beauty of Open Source software.
February 24, 2009We’re doing some GIS development with the incredible NHibernate.Spatial library, which, like all of NHibernate has very good test coverage, from what I can tell. Even so, we ran into a puzzling bug where one of the standard spatial aggregations was returning an impossible result. So I downloaded the NHibernate Spatial source code and ran the unit tests, paying particular attention to the test centered around the spatial aggregation in question. All the tests passed with flying colors, but even so, it couldn’t have been correct, we had proof of that.
The problem? Symmetry. The dummy data used in the test produced identical results with incorrect behavior as it did with correct behavior.
Here’s the data that was dummied up for the suite of tests:
"SRID=32719;POLYGON((0 0,1 0,1 1,0 1,0 0))"
"SRID=32719;POLYGON((0 1,1 1,1 2,0 2,0 1))"
"SRID=32719;POLYGON((1 1,2 1,2 2,1 2,1 1))"
"SRID=32719;POLYGON((1 0,2 0,2 1,1 1,1 0))"
"SRID=32719;POLYGON((0 0,1 0,1 1,0 1,0 0))"
"SRID=32719;POLYGON((0 1,1 1,1 2,0 2,0 1))"
"SRID=32719;POLYGON((1 1,2 1,2 2,1 2,1 1))"
"SRID=32719;POLYGON((1 0,2 0,2 1,1 1,1 0))"
"SRID=32719;POLYGON((0 0,1 0,1 1,0 1,0 0))"
"SRID=32719;POLYGON((0 1,1 1,1 2,0 2,0 1))"
"SRID=32719;POLYGON((1 1,2 1,2 2,1 2,1 1))"
"SRID=32719;POLYGON((1 0,2 0,2 1,1 1,1 0))"
"SRID=32719;POLYGON((0 0,1 0,1 1,0 1,0 0))"
"SRID=32719;POLYGON((0 1,1 1,1 2,0 2,0 1))"
"SRID=32719;POLYGON((1 1,2 1,2 2,1 2,1 1))"
"SRID=32719;POLYGON((1 0,2 0,2 1,1 1,1 0))"
"SRID=32719;POLYGON((0 0,1 0,1 1,0 1,0 0))"
"SRID=32719;POLYGON((0 1,1 1,1 2,0 2,0 1))"
"SRID=32719;POLYGON((1 1,2 1,2 2,1 2,1 1))"
"SRID=32719;POLYGON((1 0,2 0,2 1,1 1,1 0))"
It isn’t hard to imagine this limited set of three numbers combined in many different ways and coming up with identical results. While it makes for easy test writing, it makes for deceptively ambiguous testing.
In case you run into the same problem, the SpatialProjections.Envelope aggregate function for the PostGIS dialect will produce an envelope where the fourth coordinate contains two Y values, a simple transposition in a string format. A less regular distribution of sample data would have caught this straightaway.
The wonderful thing about this experience, however, was that this bug, which was crippling to the feature we were trying to implement, was easy to find, easy to fix, and within an hour we were back on track. When the patch is applied to the trunk, we can sync back up with the project, and in the mean time we won’t be implementing some awkward work around likely to break in future releases, waiting for some team somewhere to find it as important as we do. Of course, this is one of the hallmarks of Open Source, nothing new – but it is rather pleasant to experience it for yourself.













Recent Comments