I managed to waste half a day today, all because I wasn’t carefull enough.
I was consolidating the ruby libraries for the current project and I put together a rakefile to run all library unit tests before releasing them.
It’s part of the solution I use to develop libraries for several scripts:
I maintain a ‘trunk’ (subversion terminology :) ) with the code for the library and branch/copy the code for every script that needs the library.
So each application gets the libraries it needs and I don’t need to have fancy installs or dependencies to gems for libraries that are never going to see the public light, while keeping development on a single source.
Updating to the newest library version is all a question of merging the trunk into the branches. Given subversion’s ‘cheap’ copies it’s a pretty nifty trick. Ofcourse, updating is a rake task and is done automagically and only if the unit tests succeed :).
The problem this time was that although all unit tests run succesfully when run one by one (open file in Scite, press F5, be happy!), the rakefile reported one failure.
And it didn’t make any sense! It shouldn’t happen! It couldn’t happen!
I went through the developer’s classical reaction for all of 10 miliseconds and proceeded to disect my unit test to see what went wrong.
After a couple of hours and although I had found a couple of racing conditions and made the whole test suite more robust, the rakefile kept failing on that one test. Grrr!
By the process of elimination (start with the one unit test and keep adding until everything fails again) I found the culprit:
Me!
I used several mock objects to test module inclusion and drb servers and I happened to use the same name (MockAction) in two different libraries.
Now, since I had several Mock objects I had them in a file that was ‘required’ into the unit tests.
You can guess from here: Same name, different class, the later require overwrites the class needed and voila!: failure.
The thing is, if rake had loaded the unit tests in a different order, I wouldn’t have found it.
Well, the mock objects are now in a module safely ‘namespaced’ and I am a bit wiser on what can go wrong.