LD.
Music, software, life… and stuff.
[ Twitter ] [ GitHub ] [ Linked In ]
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.
Posted: Jun 21st, 2008 @ 4:25 am
