Summarizing ICONIXTDD

Summarizing ICONIX+TDD

Following the combined ICONIX+TDD process, we wrote fewer unit tests than we would have using TDD on its own, because we systematically wrote the tests following the controllers on the sequence diagrams. We also were able to write specific tests for each alternative course.

We also thrashed out most of the design details simply using robustness, sequence, and class diagrams. The unit tests then acted as an additional design-review safety net to catch any design issues we may have missed. The result was that we ended up with a realistic, well-factored design before the “guts” of the implementation code had been written, saving time that would have been spent refactoring code later.

What’s interesting is how each method (ICONIX+TDD versus vanilla TDD) leads us to implement different parts of the system first and to take a different approach:

• With ICONIX+TDD, we tend to implement more of the system up front, but we get the overall system finished in less time because we’re writing the code in larger chunks (as defined by the design model).

• With vanilla TDD, we implement less of the system in each sitting, and we do it in small baby-steps, but the overall system takes longer to write because there’s much reworking of existing code.

Because ICONIX+TDD is driven directly from the use cases (the behavioral requirements), and the tests themselves are driven directly from the objects on the sequence diagrams, we know precisely when we’ve finished. The alternative courses also provide an important source of additional unit tests, as we saw.

In addition, the design process forced us to think more about certain implementation details earlier (in particular, how the code was going to fit into the JSP web framework). However, we still produced code that would be easily transferable to some other framework, because the business logic (e.g., the validation code) was kept separate from the presentation and persistence layers.