While investigating the synergy of TDD and DbC I asked myself if there are not already development processes that combine both principles. And on my research I stumbled over this paper (PDF) named Agile Specification-Driven Development on which I want to look in this blog post.
Content of the paper
The paper (published in 2004) from J. Ostroff, D. Makalsky and R. Paige describes the agile approach of Specification-Driven Development which combines features of both TDD and DbC.
The paper starts with an introduction that states the TDD and DbC can enhance each other. Tests and contracts both are some kind of specification with benefits and drawbacks on each of them. This is equivalent to my points on types of specification some blog posts ago.
Further on the authors describe plan-driven development and DbC as plan-driven development approach. Thus they show DbC as process coupled to the design phase when mapping the complete set of requirements to the software. DbC with its contracts as specifications closes the gap between requirements and code. In the following section DbC in general with some of its benefits is described and the „quality-first“ DbC design method from Bertrand Meyer is briefly explained.
Chapter 3 describes TDD as agile development method to replace plan-driven up-front design by „stressing the development of working code over documentation, models and plans“. Striking aspects and benefits of TDD are shown as well as tests as a form of specification. The authors make a good point on what they call collaborative tests which address the interaction/collaboration of code components. Thus collaborative tests are related to UML sequence/collaboration diagrams. Collaborative tests go beyond the single-component-based TDD process which is an important insight. The next section shows the drawbacks of tests as example-driven approaches which I have shown before as well when discussing universality of tests and contracts. And the authors describe the „problem“ of contract checking: program verification as difficult task and runtime checking of the assertions which needs unit tests to stress the contracts. This again mirrors my thoughts on checking correctness.
The SDD process
Chapter 4 contains the description of the Specification-Driven Development (SDD) approach as combination of TDD and DbC. It starts with a motivation for this movement:
„There are surprising commonalities between TDD and DbC, particularly: both contracts and tests are specifications; both TDD and DbC seek to transform requirements to compilable constructs as soon as possible; both TDD and DbC are lightweight verification methods; both methods are incremental; and both emphasise quality first in terms of units of functionality. We claim that it is not necessary to choose between the two approaches a priori, and that there are substantial benefits to using TDD and DbC together in a project.“
The picture on the left side shows the statechart of the SDD approach. It’s important to see that SDD doesn’t dictate where to start with development. The authors state that „it is the developer’s choice whether to start with TDD or DbC based on project context“ while „the emphasis is always on transforming customer requirements into compilable and executable code“.
Note that SDD takes three sub-processes into account: DbC on the right, TDD on the bottom and collaborative tests/specifications on the left. You can switch between these three processes at any time, it’s up to your interpretation and you are responsible to find a valid workflow…
The authors say that „SDD provides more than TDD or DbC individually, as it eliminates some of the limitations with each approach“. And for them „SDD is more than the sum of TDD and DbC, as there are synergies between the approaches“.
Another point is made on contracts as test amplifiers. Contracts can help to drive the production of tests since they show requirements to call a code component and the conditions that should hold in return. And tests should validate/invalidate pre- and postconditions to show the correctness and the appropriateness of contracts.
The description of SDD ends with some observations and the recommendation to prefer writing unit tests before contracts. However it doesn’t make a statement whether to start with TDD or with collaborative tests and how the process should look in concrete.
The paper closes with a short conclusion and a table as summarization of those conclusions.
Two synergetic advances of SDD are pointed out:
- Contracts are test amplifiers,
- Contractual and collaborative specifications provide lightweight verification of the design.
Thoughts on SDD
SDD mirrors some of my thoughts on the synergy of DbC and TDD and I think it’s a movement in the right direction.
Otherwise for me the paper makes too vague statements and it’s only scratching on the surface. SDD doesn’t describe a clear process of how to manage DbC, TDD and collaborative tests. The given statechart is nothing more than a collection of those three principles and doesn’t state how they can be used in combination. For me it has a too „academic“ touch and isn’t worth much for a practitioner. Just to say „use these parts in combination and decide for yourself“ doesn’t help, especially beginners need clear rules and a clear process to get started to use DbC and TDD in conjunction. Thus I can’t agree with the authors that SDD is more than the sum of the parts. Perhaps it is, but the paper doesn’t clarify this.
Furthermore the paper doesn’t make a strong statement about the combination of tests and contracts. One sentence says that tests should exercise the contracts by validating and invalidating each pre- and postcondition. With this the appropriateness and correctness of contracts should be ensured. But manually writing tests for the contracts doesn’t make sense in my opinion. This would mean to duplicate the contract-based specification logic with an equivalent test-based specification logic. The contracts already contain the necessary information for the tests and thus they should be used as test oracle by automatic test generators like Pex. Moreover the paper doesn’t give any usage advices for tests and contracts. It doesn’t clarify for which specifications you should write contracts and where you should use tests. But this is a central question which has to be addressed by a synergetic development process.
In summary SDD is a first step in the right direction and fits into my thoughts on the synergy of TDD and DbC. But SDD as described in the original paper is too vague to form a new development process based on TDD and DbC. It lacks clear statements about the combined usage of TDD and DbC, but just those statements are needed for the establishment of a new development process.
