Search This Blog

Loading...

Saturday, July 26, 2008

Testable Code? Who Cares?

It's refreshing to see the post How to Write 3v1L, Untestable Code on Google Testing Blog. The post is fun to read, sarcastic and straight-to-the-point. If you want to secure a life-time employment, by all means, read the post and practice all the tips! I am sure that your employer can never fire you after that.

But if unit testing and writing testable code are so important, why the majority of the developers are not doing it? Software bugs are costing the U.S economy 60 billion a year, surely software companies can use some QA, and unit testing is definitely a must. But why nobody in the management levels seem to care?Why TDD and Agile Programming practitioners are still minorities, beyond the blogsphere?

I think this is because of the fact that, unfortunately, the benefits of testable code are not immediately obvious. Software are driven by business, business wants to see results, immediately. Unfortunately, doing unit testing won't bring instant gratification. In fact, doing unit testing seem to slow down the development at first. Lagging behind the schedule because you want to improve your code quality isn't really an option for the sales.

The non-IT managers won't care about testable code. All they care is bottom line. All they care is whether the software deliver in time. Of course they do care about software quality, but when they do it's usually when the software is so buggy that the complaints reach the heavens. But by then the damage has been done. 

For managers with programming experience, they might know the importance of unit testing, they might want to enforce coding qualities, they might even want to make the code they responsible testable. But somehow along the development, when schedule is slipping, they might just have to give in to the pressure. When their subordinates are not doing unit testing under various pretexts, what can our enlightened managers do? Can the managers force the developers to do unit testing? They can't. Can the managers do some of the tests themselves? Well, possible. But only for starters. The options available for managers when dealing with uncooperative developers are extremely limited.

Writing spaghetti, unmaintainable code is much more easier than written testable code. For a developer to write maintainable code, he has to have a lot of experience in programming and must be constantly learning.  A developer needs to know about mocking, separation of concern, dependency injection, law of demeter and other things in order to write clean, testable code. Unfortunately, most developers don't seem to care much about the software design and coding quality. The ego of developers forbid them from being taught by other developers. Is there any wonder why most code is hard-to-read?

Not only that, writing maintainable code can be harmful at times.. well, I don't want to elaborate on it but interested readers can refer here and here for a few.. hmm..."stories".

Finally, a lot of developers are not writing new code; they are maintaining old code( whether it's written by them or other people) that is not testable anyway. Patching spaghetti code into maintainable code requires resolve and skills that are beyond most developers. And to be fair with them, even experience developers have a hard time to do just that. When you are fixing software bugs you are already in firefighting mode, do you still care about source code quality in general? Do you still have the time? I don't think so.

So, writing testable code is hard, very hard. And the benefits it's not obvious. No wonder we are still talking about writing testable code as if it's the latest discovery instead of having every neophyte writing good, testable code.

4 comments:

tea42 said...

The problem I have with TDD, or BDD for that matter, is that you have to already have a "design". But most of the software I write isn't designed, but rather evolves. It's only after a considerable period of stability sets in that it seems worth adding tests.

Anonymous said...

Err tea42, you have obviously never done any TDD have you.

It goes like this. Write a small test. Write just enough code to pass the test. Then write a bit more of a test, then write a bit more code. And so on in cycles of the order of a minute or two. You very much evolve your code this way! A good example is a parser. Write a test to parse a blank line. Then write enough code to parse the blank line. Then write a test to parse a single element. Then write enough code to parse this single element, and so on. Lots of refactoring along the way. When I first started I never believed this approach would lead to good code, but believe me it does. It is amazing what you think you need when you start turns out to be completely unnecessary.

As for why write testable code? Testable code tends to have to be loosely coupled so that you can use fixtures and mocks for things. This tends to force you into a better design.

Really if you are not writing testable code you are a clown. Once you have unit tests over your code you have confidence that it works, and with confidence you can move at speed. Otherwise you spend so much time debugging your broken crap after the fact and less time writing features.

tea42 said...

I don't dispute the value of tests.

I'm talking about prototyping as a means of discovery of a nice design. Writing tests during that process it's largely a waste of time since the API is changing so rapidly. You just end up re-writing tests.

There's nothing wrong with writing tests later -- as long as they do eventually get written. A good test coverage tool can be very helpful here, and save you even more time.

The idea that a test system might encourage better design if used from the get go, because it requires the creation of good (and thus easily tested) interfaces, has some merit. But for a practiced coder that's not going to matter much.

nbuster said...

writing grammatically correct articles seems to be very hard as well.

Just like code testing, proof-reading is a virtuous task that may save you quite a few embarassments