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.