I just got back from JAOO2007. One session of the conference was James Coplien’s “Scrum Architecture”. After this session, a discussion took place about Coplien’s statement that “TDD harms your architecture”! This discussion continued afterwards as an Open Spaces debate. I had the chance then, with the help of Floyd Marinescu, to organize a filmed debate at InfoQ’s studio between Bob Martin and James Coplien on the same topic. I really enjoyed this debate which really showed a high quality spirit of discussion from both sides. Both had their arguments. I will not tell my opinion but rather let you judge yourself once the video is out on www.InfoQ.com .
Recently, I posted about the fact that I always write tests before code, but I don’t do Test Driven Development where I discussed the way I view testing. Yet I don’t guess I’ve been clear enough, so I decided to write few lines trying to better reflect the way I view a testing approach.
When I have a domain problem at hand, first what I think about is partitioning and abstraction, which means dividing the domain into sub-domains. This partitioning procedure is not driven by any tests, but rather by domain knowledge acquired from domain experts. This is extremely important; the architecture/design should reflect the domain/sub-domain problem it is trying to solve. This helps the software be flexible adopting business changes, as it was designed from a business perspective. A book that explains very well this approach is Eric Evans’s Domain Driven Design.
This Up-Front analysis is not defining the full up-front architecture, far from it, rather defining good bases for an architecture that maps to business. It shouldn’t take much time, just enough to help going forward with an iterative approach. This should define, either in code or in a tinny UML sketch, an object structure that forms the basic sub-domain’s components.
After defining the main structure of the sub-domain’s solution, I follow an iterative process as follows:
1: Driven by the business knowledge crunching, I define a component’s contract with its invariants and conditions
2: I write a test that forms the specification of this contract and its invariants
3: I start the implementation to satisfy the specifications I defined in the test
A very important note here is that the contract specifications should be readable, very clear and explicit. This explicitness helps to have a better vision of the whole system while reading the contracts-invariants of its defined components. This also helps spot bugs without the painful debugging: this approach of Design by Contract reflects developers understanding of the business domain in a more explicit way, so it makes it easier to spot misjudgments developers might have done in their implementation. This intention revealing method of development highlights important business rules, rather than letting them hidden behind an abstraction. Abstractions should not hide any important business concern as an implementation details. Explicit contracts and invariants allow business experts to have a look on what is going on inside the software. For an example of bugs that result from developer’s misjudgment see Reganwald’s recent post .
Of course unit tests are not the best tools for this approach. They work fine if we emphasize on methods and class naming for readability and visibility of invariants and rules. Still I prefer tools like BDD or Eiffel/Spec# Design by Contract. Hope we will have some more support for such tools in the industry soon.
A metaphor James Coplien used to illustrate the problem in Test Driven Development approach, which made sense to me, is a test driven course in a school. It’s about a teacher that finds that most of his students fail in the final test. So to make things work better, he decided to ask the students to write themselves their tests by the beginning of the semester, and then to let them pass these tests by the end of that semester! Hence, they might get better grades, but that doesn’t mean they got better knowledge at all.
Â
