(This isn’t for you. This is a love letter to my unit tests, who deserve it, who deserve a 5 am stream of consciousness homage.)
Slow builds really bug me. And having lots of unit tests is no excuse for a slow build. If you think they are, there’s something you’re not doing right.
This past week or so I’ve been much more active working on CruiseControl, and so the slow build time — 15 minutes for a release build? ridiculous! — were wearing away at my nerves. Even the subproject main was now taking 4 minutes to build, and I remember being unhappy when it got to 90 seconds. Something had to be done and tonight was the night.
Oh look, that one test class it taking 2 minutes all by itself. Why?!? It’s not doing anything very interesting. Hmm, any good free profilers out there? A google suggests not, so printf debugging profiling it is…
The setup method is taking 10 seconds? Well that’s bad… Delving…
getServerName() take 5 seconds each… ah,
getServerName()! But all that’s doing is getting the server name with
InetAddress.getLocalHost().getCanonicalHostName(). How about we cache the result? I mean how often is the host name going to change? Cache and run the test. 32 seconds! One change to go from 126 second to 32 seconds? How about the subproject build? Down to 2 minutes from 4?! This is going to stay.
I wonder how many other places in the code we’re getting the server name… Oh, a bunch! Extract out
ServerNameSingleton.getServerName() and use everywhere. Run build…
15 minutes to 7 minutes, for making one simple stupid change. That I found from investigating a slow test. And that I would have botched if it hadn’t been for another test.
Man I love my tests.
(Ok, now I can sleep.)