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 James Shore's often-cited 2005 blog post, "Microsoft gets TDD completely wrong," that many other folks have misunderstood TDD to mean, "write ALL your tests first." ( http://www.jamesshore.com/Blog/Microsoft-Gets-TDD-Completely-Wrong.html ) By contrast, OpenUP points out that "TDD = TFD + refactoring." That is, it fully embraces the standard notion of the TDD workflow as "red, green, refactor": 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
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
