guilty of untestability – intro :)

Tomo writes how to mock static methods and how cool is JMockit. This gives me an opportunity to write about something loosely linked with his post.

No offence Tomo ;), but I don’t believe that the class is difficult to test because I don’t know enough mock libraries. The class is difficult to test because its design sucks. Static methods are difficult to mock and I am really pleased with that. At least developers will avoid them in order to keep the code more testable. When you introduce new shiny pattern of mocking static methods other developers may follow you. That means more and more static methods.

However, there is something else that strikes me. It’s the acrobatics around the test code in order to test a class. It should be other way around: if a class is difficult to test then stop hacking the test code and refactor the class. The best approach is obviously TDD – you always end up with testable classes.

I’m not talking about static methods any more? Good. I’m not really against static methods. I love them, we should all love them and keep them safe on 3.5 floppies among other turbo pascal code.

This supposed to be an intro to more interesting stuff but ragging static methods gave me weird and unexpected pleasure. Oh right, I’m not that zealous to treat all static methods with a flame thrower. Stuff like utility libraries – they’re fine and I’ve never needed to mock them. Tomo defends static methods bravely (see comment below). He is right but mocking static methods still smells funny… If the class is difficult to test I just wouldn’t challenge the test code. I’d rather try very hard to make the class under test easy to test.

I rant about it here.

One Response to guilty of untestability – intro :)

  1. […] recent post inpired a friend of mine to write about the untestability of the code. Go check the entry before reading further, because it a […]

%d bloggers like this: