LD.
Music, software, life… and stuff.
[ Twitter ] [ GitHub ] [ Linked In ]
The warm blanket of test coverage
A recent email identified that Gldapo struggles to work with password type attributes. I suspected this was going to be the case, but had pushed it aside in the hope that no one would hit the problem until I had time to look at it. Passwords are a bit of a funny case as they aren’t really read/write, but there are cases when you do want to read the encrypted password hash.
It turns out that the problem was that I was reading raw context attributes as strings, when I should have been reading them as objects. Passwords seem to be stored as an array of bytes which can’t be cast to a string. The fix was not that difficult, but it’s fairly low down the stack. Any change that far down could easily have unexpected repercussions.
It pays to have tests
This isn’t a new idea by any stretch. But a couple of times I have wondered if I am going a little overboard with the tests for Gldapo. I don’t know what my actual coverage percentage is (there is no real solution for Groovy projects built by Maven for coverage at this time) but I suspect/hope that its > 85%. I try to be vigilant about tests for any new feature or change. As an aside, Gldapo development has been a great tool for learning how to test (and coincidentally how much easier testing is with dynamic languages).
The end result
Because of the good test coverage, I was able to make this change and verify that it did not break the public API. I did have to rejig some tests that tested internal API though. This is good news! I know at least this bug fix won’t break any Gldapo 0.6 applications when they upgrade to 0.7.
Posted: Jun 25th, 2008 @ 6:06 pm
