Sadek Drobi’s Blog

On JAOO 2007 I could, with the help of Floyd, organize a debate between Bob Martin and James Coplien about TDD and DbC. This is the most interesting debate about the subject I’ve ever heard of. A lot of things I wanted to say have been said here. And I am proud to announce it

http://www.infoq.com/interviews/coplien-martin-tdd

Thanks Cope, thanks Bob.

This post has been originally posted on infoQ on Religion driven industry: buzzwords and checklists vs. thinking and inspection

James O. Coplien has recently argued that today’s industry is based on buzzwords and checklists. The use of some techniques and methodologies, TDD for instance, has become “a religious issue”. This prevents from inspecting possible tradeoffs and focusing on finding solutions that would be the most appropriate and the most cost-effective . (more…)

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.

It is always a hard choice for such an interesting conference, I scheduled my first day, still couldn’t decide about some session. I’ll be trying to make some sort of live coverage with my laptop as I did for QCon2007