| [epf-dev] Is TDD a poison pill? |
|
OpenUP is a minimalist instance of the Unified Process for
small teams that want to use agile practices. So, there’s no question that in the latest OpenUP (soon
to be 1.0), Test-Driven Development (TDD) is a core part of the Development
discipline right out of the box. That is, I think it’s fair to say,
“If you’re not doing TDD, you’re not doing OpenUP.”
At least, you’re not doing the Capability Pattern: Develop Solution that
ships with OpenUP (you could easily tailor TDD or even unit testing out of
OpenUP if you wanted to, but WHY?!). Lately, I’ve been wondering if TDD is “too much
to start with” for many organizations that are just adopting agile
practices, and look to OpenUP as a low-ceremony process to start with. Interestingly, when I brought this up with Brian Lyons, he
pointed out that the latest IEEE Software magazine is dedicated to several
articles about TDD, including one about extending the practice to database
refactoring by Scott Ambler (an EPF committer). It’s clear that the
practice is proven, well understood, produces immediate benefits, and is
increasingly mainstream. However, I’ve still seen a lot of organizations we
consult with struggling to get started with unit testing, let alone TDD. I
took an informal survey at Number Six Software of how many projects that call
us already have any real unit testing coverage. We think it’s less
than 1 in 20. I acknowledge that we’re consultants, so by the time
a client calls us in, a project has usually been troubled for a while, so that
number is probably below the industry average. Still, don’t we want
troubled projects to benefit from OpenUP? I’ve talked to a lot of otherwise “hard core
developers” over the last two years, including a few committed JUnit zealots,
who just couldn’t bring themselves to embrace “test first.”
Why? Almost invariably the answer is, “It’s too hard to
anticipate all the tests ahead of time.” One developer, whom I
respect, recently noted that, “I spent a bunch of time writing tests,
trying to design the object as I went, but not writing any production
code. When I finally started writing production code, I had to constantly
change the tests. I don’t know, it just seemed like a waste of
time. Maybe I’m doing it wrong. It’s just easier to
write the tests after I get the production code working.” Though he’s
a strong unit testing advocate, he prefers developer tests to prevent
regressions and document the expected behavior of the code, not as a part of
the incremental process of writing production code in the first place. I suspect from You write a few lines of failing
test code, make it pass, refactor (with passing tests), and repeat. *** So my question is: Is TDD a poison pill in OpenUP?
Will organizations that would otherwise get all the agile “good stuff”
and the structured lifecycle of the unified process fail to adopt OpenUP because
TDD is “too hard?” *** I don’t think so, and here’s why: 1) OpenUP makes
the micro-incremental, “red-green-refactor” workflow of effective
TDD explicit in the Develop Solution pattern. If you’re following
OpenUP’s process description here, you can’t possibly make the “write
all the tests up front” mistake. These ideas are further reinforced
by the Guidance. 2) For new
projects TDD is the best way to introduce effective developer testing in the
first place. TDD creates a tight feedback loop: write a minimal failing
test, write the minimum production code to make it pass, refactor if needed,
repeat. This takes minutes, not hours or days. That means that developers
create good unit test coverage AS they develop production code, dramatically
reducing the vicious cycle of “finishing” a module of production
code, but “never having time” to write unit tests. TDD makes
unit tests part of a developer’s daily routine, not an afterthought. 3) For existing
projects with low test coverage that are just adopting OpenUP, the explicit TDD
practice helps them to incrementally introduce better unit test coverage.
This actually lowers the barrier-to-entry for projects that have struggled with
unit tests in the past. Just start with tests for new production code and
changes. Sorry for the long post. What do you all think? Thanks! Nate Oster |