This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I have not read the book; however, I did read the summary on the web site. How does this type of testing work when there are multiple teams involved in the change - or does this only apply during the unit testing phase. Our shop has large multi-team projects going on all of the time. How would this development/testing methodology work in our environment?
[edited to use a meaningful subject line - was "Yet another Lasse question"] [ September 24, 2007: Message edited by: Jeanne Boyarsky ]
I'm curious to hear Lasse's and others response to this. I find that one can use TDD even in a tightly regulated environment. The API is dictated. As long as I follow the API (and architecture/overarching design), I have some control. So I TDD the helper objects behind the scenes and the API definition I was given. TDD'ng the helper objects helps me allow some low level design to emerge. And TDD'ng the API ensures the caller's contract is met.
Originally posted by Alan Levenson: How does this type of testing work when there are multiple teams involved in the change - or does this only apply during the unit testing phase. [...] Our shop has large multi-team projects going on all of the time. How would this development/testing methodology work in our environment?
I'm not sure what you mean by "unit testing phase" but TDD as a development technique (not a testing technique, mind you) is perfectly feasible in a multi-team scenario. Following TDD, each developer is simply writing a unit test before they enhance the production code to make it pass. That's all.
Ok. That's not quite all. As the size of the team grows, it's important to integrate often so as to avoid merge conflicts.
I'm not sure what you mean by "unit testing phase"
Lasse's being modest here
I think an interesting question is this -- how much of the value of using TDD is dependent on the development process being agile or iterative, as opposed to a more waterfall-based approach, which may indeed have a "unit testing phase"? (Assuming that the process isn't so strict that it actualy enforces coding production code first and then producing unit tests after the fact, but allows development and unit testing to proceed simultaneously.)
Lasse, your thoughts?
(I'll repeat this question as a separate topic in this forum.) [ September 27, 2007: Message edited by: Allan Halme ]
<i>The lyf so short, the craft so long to lerne.</i> --Geoffrey Chaucer (c. 1343-1400)
Joined: Jan 23, 2002
Originally posted by Allan Halme: (I'll repeat this question as a separate topic in this forum.)