Month: August 2010

Testability is a design goal

Testing is important, let’s for a moment agree on that. Untested code might more likely break, now or at some point in the future. If I say “might”, then Murpy immediately corrects me and tells me it “will”. Definitely. Even if we manage to write perfect code right now, it’s still nice to have regression tests and be much more confident and agile for future changes and refactorings. Also, tests are always some kind of a proof that we tried our best to produce a good product, for us, for the team, for our boss, and, wait for it, for our customers. After all, if code breaks, every argument is obsolete, because no matter what, code that breaks is always wrong.

Besides my all-time favorite that there is no time to test, I also hear the following again and again: “We can’t really test that, it’s just not, um, testable!” Be it the Java application that doesn’t allow dependent services to be replaced by mock implementations. Be it that we’re hard-coding configurations in a way that we can’t switch to test configurations. Or be it that our web application can’t be easily tested because we don’t have ID’s in our HTML elements. Yes, that’s all legitimate reasons why code isn’t easily testable. But is it also legitimate not to test because of those reasons?

In short: It’s not.

If code isn’t (easily) testable, we have a bunch of options: we don’t write tests and ignore what we said earlier in this post. We test it in another context, maybe on an integration test level (for example). We test it manually, which is often an option, but then we’re missing out on all the advantages regarding repeatability, usage as regression tests, and continuous integration. Or, and that’s the point of this post, we’re changing our code to make it testable. Not always, but often that means introducing something that doesn’t purely serve functionality but is additionally introduced in order to make it testable. We might end up with 5 lines of code or even with an indirection more that we wouldn’t need otherwise. At least we can test it now. Or, even better, we think about testability from the very beginning (oh, and: test first, anyone?) and aligning design and implementation accordingly. Very quickly we will recognize untestable code, untestable patterns, and untestable designs at first sight and we’ll make slight but important changes. With best regards to our test coverage.

Don’t hesitate to make changes to your code to increase testability. After all, testability is also a design goal.

EDITED: looking back the few months since I’ve written this post I made more experiences manifesting testability and a very important yet mostly underestimated goal in software development. Today I stumbled upon a presentation by Michael Feathers of Object Mentor talking about the Deep Synergy between Testability and Good Design. I realize how much more further he goes with his thoughts, and how much more experience has to speak out of. 100% agreed, Michael, nice presentation!

A brand-new Groovy / Grails user group Vietnam

In previous posts I’ve already been trying to explore software development communities in Vietnam. Since I am working with Grails in one of my current projects (very enjoyable!) I thought I’d start an experiment and found the “Groovy/Grails Usergroup Vietnam“.

After letting it sit for a couple of days I almost forgot about it until someone actually found the site, became a member and started a discussion! Admittedly, the discussion wasn’t about Groovy and Grails but rather why it’s so freakin empty on this page but still, it’s a member and a discussion.

So, Java people out there, let’s just continue with the experiment, invite more people and see where it goes. The actual community might really be very very small in Vietnam but maybe even more of a reason to get together here.

You’re not sure what Grails actually is? In very short I would describe it as “Ruby on Rails for Java” (is that ok to call it that?) and as a very entertaining and light-weight way of developing web applications based on Java. For more please check out the grails.org or the Wikipedia article or Google.

If you’re interested now, please join here: http://groups.google.com/group/groovy-grails-vietnam. And if you think the idea’s even more stupid than offering shoeshine for flip-flops, then join the comments below.

My 5 reasons not to use short variable names anymore

Every other day I stumble upon lines like that reviewing code:

sysMgrH = vFgrMan

or

parse1(l, e, arr);
parse2(l2, e2, arr);

Please don’t do that anymore! Choose long and clear variable names, nothing else! Why?

  1. It’s actually allowed to have variable names longer than 1, even longer than 10 characters, if you need that.
  2. Your job is not about saving a couple of keyboard hits or 30 seconds of time, it’s about producing something of high quality. And something maintainable. And sustainable.
  3. Actually writing out the code is only 1% of your time compared to the rest, like e.g. thinking about what you should write. You can as well spend a few seconds more on the writing part.
  4. If you worry about having to write the same 12-characters variable name over and over again: make friends with Ctrl+Space.
  5. But the actual reason, my personal #1 reason, is the following: you don’t write that piece of code for yourself and for right now. It will be existing for the next 5 or 10 years and if you’re lucky dozens of developers will see it. And some of them have to understand it. In 2 months, in a year, in 5 years. But for them it’s not a matter of 30 seconds (that’s the time you saved 5 years ago, remember?), for them it can easily become a matter of hours. Keep in mind that on average more than 50% of software development costs are spent after the initial version is finished.

So here is my appeal: be nice and write your code as if you’d write a novel. Choose nice words, choose long words, and format everything nicely. Think of your fellow developer in the future who will thank you for that.

    Also, be aware of The world’s two worst variable names by Andy Lester.