Search This Blog


Tuesday, December 11, 2007

Why TDD not practiced?

TDD survey results revisited had an interesting post on the how well the Test Driven Development, or TDD among software organization:

Does your organization actively practice test-driven development (TDD)? Chances are, the answer is no- at least based on the results of a survey distributed at Stelligent’s TDD roundtable, which found that the majority (84%) of the survey respondents aren’t practicing TDD, and 79% said they do not measure code coverage for development projects.
Why TDD is not actively practice?

Here are my 2cents.
  1. The management not concern about unit testing because it doesn't yield tangible benefits straightaway. Can you PROVE that doing unit testing speeds up your development and reduce bug count? Yeah, maybe some may feel that. But to prove it using graphs and metrics are not easy.
  2. The developers do not write their code with testability in mind. Instead, they write code to accomplish a feature. And when the problems come, they want to fix the problems., not write test first and only then fix the problems
  3. The software organization needs to maintain legacy applications that are poorly written and have no unit test coverage. And you know how hard it is to unit test the legacy applications.

Further reading: Barriers remain for test-driven development


Anonymous said...

In other words:

1. Unit tests should be accepted good practice for software writers and should be required by law.

2. Before refactoring:
2.1 Write the corresponding functional tests and the corresponding unit tests. One of those must fail before you change the code.
2.2 Document all the smells before doing the refactoring, so that later on you can assess how much smell removal has been done.

3. Make sure the customer is willing to pay for those smell removals. What are the higher priority issues? Are they related to any of those smells?

Anonymous said...

Also make sure you run all your tests during the compilation process (using ant or maven is required).

This is important for early detection of bugs.

"A bug introduced during N days of work will be detected randomly and be fixed in N days of work."

Therefore, put unit tests in place to avoid check-in defects in the first place, so that you spend zero days fixing bugs because they can't be introduced in Subversion.