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.

A case for Maven (making Gldapo testing easier)

Gldapo uses Maven which, for those uninitiated, is a new generation build system based on that ever popular idea of “convention over configuration”.

There is a lot of maven hate about the intertubes. I am not going to get into that now (I'm on the pro side if you are wondering). What I do want to show is how I was able to add a really cool set of tests to the Gldapo build with very little effort.

The Problem

While developing Gldapo, I was routinely having to make assumptions about how the directory server would respond to different things. Sure, I could read through all the RFCs, but that hardly sounds like fun.

These assumptions would go into the mocks and stubs I would use to test the library. But assumptions are just that, and we all know what they make out of you and me. There are no publicly writable LDAP servers out there, so writing tests against external servers wasn't a possibility.

So what I needed were full stack tests that tested Gldapo against real live LDAP servers. This was the only way I could be confident that the damn thing worked.

The Solution

This is a familiar problem to DB people. In so much that the need to embed a DB in your tests and run your domain tests against that. I ended up stumbling across the Apache Directory project (I did know of it's existence, but didn't know it could help me in this context). Hmmm, a 100% Java LDAP server just might be embeddable in the same way that HSQLDB is.

Then, I hit this beacon of light. Could I ask for anymore?

Why Maven Rocks

So the Apache Directory project had done the hard yards for me which I am more grateful than I can express. But this is a post about Maven.

Because the Apache stuff was available in the central maven repo, integrating into my project took 12 lines. Seriously, that's pretty hot. Add in a Groovier version of their abstract test base and we are in business. So in very little time I had unit (integration?) tests incorporated into my build that tested Gldapo against a real live LDAP server.

This is a great example of where Maven's standardisation of the build concept saved me a ton of work. I don't want to be messing around with build scripts. I wanted to use something in my build; all I had to do was declare it in my pom.

It get's better

So, I need to test write operations. Hmm.

Obviously, making the writes with Gldapo, then reading the entry back with Gldapo to test the result is less than optimal. It would be great if I could use a different LDAP library to read back the entries after writing (therefore eliminating any posibility of Gldapo masking it's own bugs).

Sure, I could of used straight JNDI. But if I wanted to do that, why would I have written Gldapo? So I found an LDAP library from Novell that is pretty low cost in terms of setup for read ops. This library is available in the maven repo, so adding it was trivial.

Yeah… and?

Now nothing happened here that couldn't have happened without Maven. It's just that Maven made it ridiculously easy to do. It allowed me to focus on the actual task at hand rather than having to glue stuff into my build and ship around dependencies with the source.

So the end result of all this is that I can write tests like this and release Gldapo with more confidence.

Maven TextMate Bundle

Some time ago, my Maven bundle for TextMate went live into the main repository. I encourage anybody working with Maven on Mac OS to check it out. I couldn't live with out it now.

My favourite feature would have to be the scoping of Groovy source in your POM if you use the Groovy plugin and specify an inline script. This makes all the snippets and niceties of the Groovy bundle available to you when writing inline scripts! Let's see IntelliJ do that.

Maven & APT TextMate Bundles

I have started TextMate bundles for Maven and APT. They are currently in the review section section of the bundles repo.

Update (2008-03-04): The Maven bundle has been promoted to the main repo.