The next web killer app

During the last weeks I’ve made my mind up about social networking and my ideas of how the next web killer app could look like. Now I want to share some of the rough ideas I have towards this topic.

Location-based and mobile

FoursquareI strongly believe that the next web killer app will be a location-based service, which combines the expressiveness of social networking with the flexibility of creating virtual spots in the real world and interacting with them. First popular candidates in this area are Foursquare and Gowalla. GowallaBoth systems are very similar: users can define locations, share them with their friends and can check-in at a location to show their friends where they currently are. Actually both systems are games as well: you can „earn“ virtual rewards e.g. by checking-in to many different locations or you can become the mayor of a location by checking-in at this location more often than all other users. This ludic portion combined with applications for the most popular mobile platforms (BlackBerry, Palm Pre, Android, iPhone, …) makes them successful ascenders.

GeocachingGeocaching is another example for a great location-based service and it’s not just virtual. People can hide little containers (caches) in the environment and publish the coordinates of those caches on the Geocaching website. Other people can check out those coordinates and (in its simplest form) search for the caches at the specified location. In bigger containers there are little things which could be traded and which travel from cache to cache. Thus in contrast to a virtual reward system you get real physical experiences and things to trade. Geocaching animates people to go „back to nature“ and is a real cool movement.

In my opinion location-based services are just at the beginning. With the increasing spread of mobile internet, GPS devices and exact location detection they will emerge and a really new wave of services will come over us. Not everyone will like those services (privacy considerations come in mind), but the world is changing and digital natives are very open-minded to new cool services. Thus I strongly believe that the next web killer app at its core will be social again and will make strong use of mobile and location-based services.

In my opinion the stage is set, but current services can do much better. The next web killer app will not be limited to the ludic approach. It will be more generic and can be used for a broad range of activities, from sharing location-based information and media about private date planning to covering real business scenarios.

„Loc“ as new tune to the music

Let me introduce a new central term for a location-based entity: a loc. The system in my mind completely builds up on those locs. In its simplest form a loc can be seen as a location, but it has more characteristics that justify the need for this new entity:
Not only a location: a loc

  • A simple loc has a location and an owner.
  • A loc contains arbitrary information which can include media (audio/photo/video) and rich text.
  • A loc can be of temporary nature and could contain a date/appointment.
  • The owner of a loc can give access rights to other users or user groups.
  • Locs are interactive: Users can travel to a loc and mark it as visited („Log your Loc“ is a great mantra), they can leave comments and a rating for the loc.
  • Users should be able to search for locs in a flexible way and locs should be shown on a map, e.g. as overlay on Bing Maps or Google Maps.
  • There could be composed/complex locs that consist of several simple locs.

Characteristics of the new music style

The new location-based system in my mind would completely build on those locs and it will differ from existing applications in some important and innovative ways. I strongly believe in the following characteristics of a location-based app that builds on locs:

  • Social community: In our internet world everything is about social. We want to express ourselves, but we want to connect with friends and interest groups as well. A location-based service definitely should take this aspect into account. I should be able to define personal locs and share them with my friends and I should be able to group locs thematically. Thus I should be able to create or join groups which contain a thematic subset of locs. For example there could be a group which collects information about great places in nature. Or what about something like geocaching? There are no limits of fantasy.
  • Time limitation and appointments: Dated locs for appointments are a very important feature of the new system and make a big difference to present applications. Dated locs can be used for planning dates, meetings, partys… whatever. That’s a key element in my opinion! It’s relevant for private and social life as well as for business planning and meetings. Imagine you want to meet with some friends. In contrast to write invitation cards you could publish a loc with a date and some further information (photos and more information as rich text) and your friends will be able to easily navigate to the loc by their mobile phones. After the date the loc will be archived and marked as „done“. Time limitation is important as well. Locs with a timespan could be used for temporary information and thus make a real vibrant experience.
  • Authorization management: One important aspect that comes with personal locs and with loc groups is authorization. Users should be able to define flexible access rights for their locs, especially for dated locs. They should be able to limit the circle to certain people, all of their friends, groups or the public pool and they should be able to define rights for others (read/comment/modify/full). They should be able to publish a loc in their personal space or in a group, if they want to allocate a loc thematically.
  • Contextsensitivity and triggers: Single locs could be just the beginning. A very powerful feature are contextsensitive information. Imagine a check-in at an airport. You start with a first loc which guides you to the check-in counter. After your check-in you’ll get more locs that guide you to duty-free shops and the gateway, for example. On the flight you could get information about your destination and after the flight new locs could pop up for the target airport (baggage pickup, cabstand, rental car, …). That’s just one short example for the power of contextsensitivity. The unlock process for new locs would be based on triggers. E.g. if one loc is logged the next loc could appear and so on. Triggers are great for things like geocaching as well. Imagine you define a trigger that require that you enter a code to log the loc and to activate further locs. This code could be placed in a container you’ve hidden at the target location or could be determined by some riddle which you can only resolve on that location.
  • Different loc types: There could be a mass of different locs, each with different characteristics. The simplest form could be a single loc, thus just a single spot. Another type could be a multi loc, which consists of several single locs. Multi locs build a loc chain and it could be possible to unlock subsequent locs by triggers on previous locs. Another loc type could be a live loc, which is basically a single loc and contains dynamic content. This content could come from a feed or another data source and updates frequently. Examples for live locs could be train schedules with information about delays.
  • Notifications: Flexible notifications are important to get users informed about new or updated locs. Those notifications could be based on a special thematic (group), on a relationship to a person (friend) or a spatial dependency (in the locality). Users should be able to manage their notifications in a very flexible and easy way, they should be able to define notifications on everything they want.
  • Mobile: A social location-based service only makes sense with a social mobile device, which includes location detection via GPS and/or other technologies. Foursquare and Gowalla have done good work here. They include mobile applications for the most popular phone platforms and thus give a great mobile user experience. The future is mobile!
  • Integration: In our current world we have a bunch of great social applications like Facebook or Twitter. I believe that for a new social application to succeed it’s very important to integrate those social communities. E.g. messages and locations should be able to be published on my existing social user profiles. Integration of other great services like Bing/Google Maps is very important as well.

Start now!

So when should we start to develop such a new service? The answer: NOW! If you don’t develop it, somebody else will do.
The technology is here, we just have to use it…

Those are my first thoughts on this very interesting topic. But I truely believe in them. What do you think about my sketches of the next web killer app? How would your next web killer app look like? For sure I have further ideas in this area, so feel free to contact me if you are interested in a deeper discussion or in some cooperative work.

kick it on

MIX10: And where was Live Mesh?

Some weeks ago there was MIX10 in Vegas with several interesting topics. I was inspired by the Windows Phone 7 developer experience with Silverlight and OData as open protocol for delivering collections of data as feed in the browser. There were other great sessions as well, but I missed one big thing: Live Mesh and the former Live Framework (R.I.P.) as developer portion of it.

It has been very quiet around Live Mesh (a.k.a. Windows Live Devices) in the last months. Celebrated as rock star on PDC08 and honored with several awards Live Mesh is one beautiful example of how Microsoft is unable to place great products with huge potential on the market. News on it are missing for quite a while now and developers are confused by the sudden death of the Live Framework. At this time one fact remains: Live Mesh will be part of the Windows Live Wave 4 as Windows Live Devices, but that’s it. After getting no real news on the PDC09 regarding Live Mesh and the Live Framework many people thought the MIX10 would set the stage for the new Windows Live Wave 4. I know 3 sources of people at Microsoft who were pointing to MIX10 as well when speaking about Live Mesh and the Live Framework. But their signs were wrong and again developers get disappointed. MIX10 brought not one session or info about Live Wave 4 / Live Mesh / Live Framework and that’s a shame.

I don’t know what Microsoft is planning. I don’t know when news on the Live stuff will be published. I don’t know why there are no updates on this hot topic. I don’t know where this will end. But I know and believe that Microsoft wastes the huge potential of a great developer and end user platform which could have been used as central environment of data, apps and people surrounding all devices. The bits that have been published with the Live Framework CTP on PDC08 were great and fun to use, but they have been cut off. I just can repeat it: Microsoft is really good in wasting potential…

A look at: Contract Driven Development

Today I want to take a look at this paper (PDF) entitled „Contract Driven Development = Test Driven Development – Writing Test Cases„. Like the paper on SDD I found this essay on my research for a synergetic development approach that takes both DbC and TDD into account.

The paper was written by A. Leitner et al. at the ETH Zurich in 2007, when important steps towards automatic testing had been already made. One of the co-authors of the paper is Bertrand Meyer, the inventor of the Eiffel programming language which can be seen as cradle of DbC. Hence it’s not surprising that the paper and the described tool are based on Eiffel.

Content of the paper

The paper describes Contract Driven Development (CDD) as new approach to lower the effort for writing tests with intensive use of contracts. This approach is based on a mechanism to extract test cases completely automatically from failure-producing runs of a component, where contracts act as test oracle.

In the introduction the paper takes a short look at current developments towards automatic testing and shows the drawbacks that come with many tools. Automatic testing tools don’t know the semantics of a program and the insights a programmer has and thus those tools cannot distinguish between meaningful and meaningless inputs. CDD wants to overcome this drawback. It relies on the observation that developers are often writing implicit test cases when manually running a program to determine the correct behavior of their code. But many developers don’t extract those test cases as automatic unit tests and thus those tests cannot be run in a reproducible way.

The paper presents CDD as method that captures those implicit test cases automatically and extracts them into explicit tests. One important limitation is that it only captures test cases which produce a failure e.g. through a broken contract or other exceptions. With this approach the resulting test suite contains tests for mistakes made by the developers in the past. The developer builds up this test suite by running the application with corresponding input values. The authors state that the test suite would have similar properties to a suite as result from TDD when you write contracts before the implementation of a feature. You can find my personal thoughts on this below.

The paper describes a mechanism by which CDD observes program executions and detects the last uninfected state when a failure occurs. In this case CDD takes a snapshot of this state and a new test case for the failing component is created automatically. The snapshot serves as starting context for the test case by which the failure can be reproduced.

With this process the developer has to provide the inputs triggering a failure only once. Then CDD jumps in, saves the values that lead to the failure and extracts a test case to reproduce the failure. The developer can go forward with his implementation and can choose to fix the bug later on while the failure is saved as reproducible test case. Contracts can help a lot in this process since they can act as oracle for expected behavior and can express assertions that go beyond some technical exceptions. With this the benefit of CDD is mainly driven by a extensive utilization of contracts.

The authors finish with a conclusion of their work:

This article explains the fundamentals of the Contract Driven Development approach. A tool autonomously observes the developer while he is working on a program and extracts test cases from failures either provoked by the developer (in the spirit of test driven development) or by mistake (leading to a regression test). The approach is novel in that complete test cases are extracted not only from the information provided by the system under test, but also from non-permanent clues given by the programmer during development.

My thoughts

Personally I feel a little ambivalent about the CDD approach. First I like the idea of making implicit test cases which are run by the developer explicit by extracting them automatically. This includes the developer’s knowledge about the context of an application into the generated test cases and thus goes beyond the technical aspect of automatic testing. It takes some work on writing test cases from the developer’s shoulder, but it doesn’t have as many advantages as one may think…

Expected functional behavior can be defined by contracts (postconditions, invariants) which act as test oracle for CDD. But it’s a limitation as well. Important characteristics of code are difficult to define with contracts while they can be easily defined with explicit unit tests (aspect of expressiveness). Thus CDD is limited in its expressiveness as well.

Furthermore CDD extracts tests for failing runs only. But what about the other side of the medal? For successful runs no test case will be generated automatically which leads to the problem that if anything in the code changes there is no possibility to check the successful tests without running them manually again. Thus CDD is not suitable for complete regression testing.

Last but not least the authors state that a test suite created with CDD is very similar to TDD (beside other parallels to TDD). Moreover the title of the paper gets it to the simple formula „CDD = TDD – Writing Test Cases“. Here I strongly disagree! CDD and TDD have very different properties. TDD takes things like code design and specification into account, is well-suited for documentation purposes and creates a real regression testing suite. None of those aspects is in scope of CDD, so TDD goes far beyond CDD.

At the end I think CDD is an interesting approach, but the benefits are bought dearly and eaten up by the drawbacks. One of the most serious drawbacks for me (personally) is the design aspect. If you rely on CDD you are not driving your API design to be clear and lucid. There will be no unit tests for which you want to have loosely coupled components and furthermore CDD will everytime run hard against your concrete infrastructure.
To make a final advice: The only scenario where I would use CDD is for automatic test generation when running the software in production. If something fails in production with CDD you as developer could get immediate feedback about what went wrong and you could immediately reproduce the failure by running the extracted test case. This would be a nice support for bugfixing and it would be really valuable. But for testing purposes in the development process I don’t see a chance for CDD.

kick it on

Will Windows Azure succeed?

On PDC 2008 Ray Ozzie went out on a limb by saying that Windows Azure will be „setting the stage for the next 50 years of systems“. Everyone (me too) was excited about this new technology and people got inspired by Microsoft’s vision and its new cloud computing platform.

16 months later, here we are: Windows Azure is live, the platform has been consolidated (R.I.P., Live Framework…) and data centers have been built up around the world.

But is Windows Azure this game changer that Microsoft promised and which they bet on? Will Windows Azure (as product) succeed? I’m not sure, but let’s see…

First things first

My thoughts on this topic have a certain background. In 2009 my company SDX invested significant research time into the innovative areas of cloud computing in general and Windows Azure in particular. And we’re still moving forward in this area. In scope of the NewCloudApp() contest we made up a little showcase named Rating Stress Simulator which you can see on the right and which you can try out now on Windows Azure.

On the architectural side we tried to use many of the possibilities offered by Windows Azure: WebRole, WorkerRole, message queue, table storage, WCF service hosted in the WebRole, …

We gathered some experiences with Windows Azure, both on the technical and on the business side. We find the platform very promising and we believe that it’s the best cloud platform on the market from a technical point of view. It gives great flexibility for developers while still utilizing their existing technical skills with .NET, Visual Studio, SQL Server and others.

Costs always matter!

While we see a great platform we’re also unsure if we should bet on Windows Azure. The main reason for this are the fixed costs for idle hosting. This means the costs for just holding our application online and running without any user on it. For this task our simple application with two roles, a message queue and table storage (no SQL DB included!) has monthly costs of about 130€ (~177$)! The main costs come from the two running roles and I’m gonna tell you: we aren’t happy with the current situation.

And we’re not alone with our criticism. Windows Azure costs are highly debated these days and to make hosting small applications on Azure less expensive is the no. 1 request of developers who voted on the My Great Windows Azure Idea website. Several blog posts and discussions run into the same direction. When people realized that Azure computation costs are based on wall clock time and not on real CPU time they equally realized that hosting on Windows Azure is ridiculously expensive compared to other options on the market.

Let’s do another calculation example for idle costs. Let’s imagine a little start-up application with 2 roles (small instance), 1 Web DB and 1 AppFabric Service Bus connection, up and running all the time and waiting there to be used. This scenario leads to monthly costs of about 137€ (~193$), which results in costs for 1 year of 1610€ (~2270$)! Those idle costs are fixed costs for this scenario which outline the entrance barrier for just holding the application online without any traffic. Isn’t one of the basic ideas of cloud computing to keep the fixed costs low and transform them into variable costs? At least Windows Azure doesn’t follow this idea or not on a reasonable scale… Hence it isn’t attractive for start-ups and little companies which could buy and run a server on their own for these costs and get full flexibility.


But what about the offers of other companies and their attractivity? I’ll start with shared hosting as possibility to outsource infrastructure and application hosting. Shared hosting is many times cheaper in comparison to Windows Azure. For sure Windows Azure offers additional values: deployment, management, scalability. But the point is that for most people who are interested in Azure those values don’t matter much. For most people, companies and their applications those qualities are not nearly justifying the higher costs of Azure hosting  compared to shared hosting.

But let’s come to two ‚real‘ cloud providers: Google with its AppEngine offers a certain amount of free quotas and in measuring computation costs they got the right idea. Google charges only for the actual consumption of CPU time (in comparison to the wall-clock-time-based model of Windows Azure), thus you are not charged for idle time of your processes.

Amazon with its EC2 calculates on a wall clock time basis, but here you have the full flexibility of arming your VMs with everything you want.

And then there’s Microsoft with Windows Azure which doesn’t include the benefits of both models. On the one side Windows Azure charges you on a wall clock time basis and thus you’re paid for idle time of your applications as well. On the other side Windows Azure is VM-based where every „role“ depicts an application fragment that maps 1:1 to a VM. The serious drawback here is that you are not able to host more than 1 role in a single VM instance. Thus you don’t get any of the flexibility of Amazon’s EC2 VMs.

Microsoft should revise this role/VM-based scaling model and/or the wall clock time basis. With the current model it’s not attractive for hobby developers, start-ups and smaller companies. The entrance barrier is ways too high and the scalability is too limited. Why should any small company use Windows Azure over AppEngine or Ec2? I don’t know…

But what are the implications of not attracting hobby developers, start-ups and little companies? Perhaps we could learn from the past, so let’s take a look in history…

A brief look in history

Some days ago an older colleague of mine told me from the rise of Windows and the fail of OS/2 Warp (this was before my active computer time, so it was interesting to hear this story from ancient ages…). He told me that OS/2 had striking features on the technical side in comparison with Windows, but it couldn’t win the OS war. It was beaten by Windows and died a slow and painful death…

One reason he sees for this is the poor attraction of hobby developers and the inability to build up a big developer community around OS/2. Windows came with a cheap compiler which enabled everyone to write his own Windows software. Microsoft was able to attract hobbyists which resulted in a huge software pool of shareware, freeware etc. and yielded a large developer community and knowledge base to develop applications for Windows. OS/2 Warp failed in this case: the IBM compiler was expensive (> 1000 Deutschmark, that’s about 650$ in the year 1990) and even while the platform and technical features were great, nobody was attracted to develop against it due to the high entrance barrier of development costs. OS/2 couldn’t generate a critical mass of developers, development knowledge and subsequently software as output for the users.

Hobby developers matter!

I don’t get around to see parallels between OS/2 and Windows Azure on the costs side. Microsoft should learn from history and should prevent mistakes that have been done by others before. It’s crucial to attract a broad range of developers to use Windows Azure for expressing their ideas and building the next wave of killer applications. With the current costs just very few developers will be attracted to make experiences with the platform. But that’s a big mistake!

By bringing Windows Azure to hobby developers and smaller companies, Microsoft would open heavy doors to the real business. Developers and architects would take their experiences with the platform from their personal lifes to the business and would promote Windows Azure when asked for it or when to decide for the platform of a new application. Accordingly the entrance barrier even for bigger companies would be ways lower: developers who have gained experience with the platform would be able to spread their knowledge to colleagues. This builds up a chain reaction and an exponential growing amount of developers would use the platform. It would be the best promotion for Windows Azure that Microsoft could get.

For today because of the costs not many developers will suggest Windows Azure with good conscience and that’s a pitty. Please, Microsoft: Community matters! Realize the potential of your platform and the implications that come with the amount of hobby developers who are using Windows Azure.

The need for a „Mini Azure“ offer

One suggestion follows: realize a „Mini Azure“ package as new offer on your Azure platform. Low costs (<10$ per month), few resources, no dedicated machines, weak SLAs, but online 24×7 – just being there to get people started. Remove this high entrance barrier or you will go the OS/2 way down the road. Your great platform leads you nowhere and will not succeed, if you don’t have people who use it…

Mini Azure has been suggested by Jouni Heikniemi before, so take a look at what he and others say.


To summarize things: if nothing changes I’m currently afraid that Microsoft fails with Windows Azure, at least I fear it will be a non-starter. And that’s a bad basis for future development. At the moment Microsoft scares people away and they will meet problems to get them back. I say it again: I think they have a very good development platform. But the best platform doesn’t lead them anywhere if it’s too expensive for people to use this platform.

kick it on

A look at: Agile Specification-Driven Development

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.“

Agile Specification-Driven Development

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:

  1. Contracts are test amplifiers,
  2. 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.

kick it on

Comparison: DbC and TDD – Part 4

Let’s start the last part of my little blog post series regarding the comparison of DbC and TDD. This post is about code changes and the support of clean code principles by either DbC and TDD.

Code changes

Changing code is a big challenge for ensuring software quality and software design as well. It’s an important but often underestimated topic. If new features should be implemented or existing requirements change you should be able to change your code in a way that ensures correctness for the behavior of the new and the existing code base and you should be able to keep a consistent design.

With TDD you set up a nice test suite and tests can be run in a reproducible way. If requirements change or are extended and you adapt/extend your code, with TDD you first have to rewrite and/or extend your tests to fit the new set of requirements. But then by running your adapted test suite you can catch unexpected side effects from your code changes. This regression testing is a great safety net for those changes. Without such a test suite how could you be sure that the expected behavior still holds after the code has changed? Tests in a TDD way are great for continuous integration. When a developer in your team changes code and performs a check-in, with clear unit tests you are able to validate the changes during a continuous integration build. With a constraint on the minimum value of allowed code coverage this gives you a great confidence that a code change has no side effects which affect the expected behavior of your components. Moreover TDD ensures a more consistent API design over code changes. By writing tests before implementing new requirements you continuously adapt your design from a client view.

A drawback of tests is the effort to manually write and adapt tests. When behavior changes and old tests fail you have to investigate why those tests fail, thus what the old behavior has been and if this behavior has changed or if your implementation is simply wrong. With huge test suites maintainability can become a very time-consumptive task. Another important issue with TDD and automated tests in general is that any developer who joins your project must have a good comprehension for the TDD process and for automated tests. For many developers TDD is not very intuitive at the beginning and it’s overwhelming them by completely exchanging their development styles and habits. Becoming familiar with TDD could be an important gap for developers and giving all developers in a project the same comprehension for the process can be difficult (especially if they don’t see the benefits of TDD). That’s a question of accountability and project lead. There have to be project guidelines which include testing standards and there must be mechanisms to watch the adherence of those standards.

DbC can’t give you huge support for code changes out-of-the-box. If you only rely on runtime checking of the contracts you could not make a statement if an implementation still holds the contractual specification when code changes. Moreover you have to manually adapt your contracts when you change an implementation. There’s no direct mechanism besides the limited static checking that ensures the correctness of your implementations in terms of the defined contracts. The only solution is to set tests in place that validate the contracts for exemplaric input/output pairs. With such a test suite you can check in a reproducible way if your implementation still mirrors your contracts. But note: I don’t say that tests for contracts should be written manually. In my opinion it doesn’t make much sense, because both tests and contracts are a form of specification and with manually testing a contract you would duplicate the specification code! Moreover contracts already contain the relevant information which is needed to set up a test automatically. Solutions like Pex can jump in here to generate tests from scratch or from parameterized unit tests, using contracts as test oracles for accepted input values (preconditions) and expected output (postconditions).

Contracts have a gap for developers as well. Contracting can get messy and confusing if you are not able to give the developers on your project the very same comprehension of DbC: how and where to use contracts, limits for contract definitions and so on. As further drawback there is no possibility to check the percentage of contracting in a fashion of code coverage in TDD. A developer with no commonsense for the process could leave contracts and nobody would recognize and react. Again it’s the responsibility of the project lead to give guidelines on contracting and to observe the adherence of those guidelines.

Clean code principles

TDD and DbC both give great support to some important clean code principles and thus improve the software quality far beyond the bug prevention aspect.

  • YAGNI (You Ain’t Gonna Need It):
    DbC cannot support you here, but the TDD process greatly supports YAGNI. For each new feature you write a test which leads to an implementation that reflects the test suite and which contains only those features that are really necessary.
  • SRP/SoC (Single Responsibility Principle/Separation of Concerns):
    Both DbC and TDD support those principles. TDD has less impact, but in my opinion with TDD you early discover the dependencies of your components and thus you are encouraged to keep components clean. DbC is more offensive in terms of SRP and SoC. It’s difficult to write contracts for components with many responsibilities and thus DbC directly enforces a separation of concerns.
  • KISS (Keep It Simple and Stupid):
    Both TDD and DbC add some value here. With TDD due to the incremental evolution an API is kept simple and client-friendly. For DbC the same rules apply as for SRP/SoC: It’s easy to define simple and stupid methods with clear contracts, but it’s hard to define contracts on complex and messy components.
  • DRY (Don’t Repeat Yourself):
    I don’t see support from TDD, but DbC influences the DRY principle. Because DbC introduces contracts that clarify benefits and obligations in client/supplier communication it prevents clients from checking return values and parameters redundantly. For example a postcondition says „the return value will never be null“. Thus there is no need for a client of the method to check the return value before handing it to another method that expects a non-null value as argument. This would be encouraged when you do defensive programming, but with DbC you can really prevent such redundancies.
  • OCP (Open/Closed Principle):
    I don’t see big influence from both DbC and TDD here. OCP states: „Software entities should be open for extension, but closed for modification“. This means that your components should be easily extensible without the need for code modifications. OCP increases the level of abstraction and the code complexity, but it makes components easily extensible. With TDD you drive your API only for a current feature set and there seems to be no impact on extensibility. DbC with its contracts can’t help you here as well in my opinion.
  • ISP (Interface Segregation Principle):
    Both DbC and TDD support the ISP. DbC influences ISP by the enforcement of SRP/SoC. When you set contracts on an interface with many responsibilities/members it would be painful to write invariants that must be maintained by each interface member. But it’s  pretty easy if you have clear and simple interfaces. For TDD the impact is less, but it’s there since you early discover dependencies and you drive your API in a „segregated“ direction when implementing tests for new features.
  • DIP (Dependency Inversion Principle):
    Support for this principle mainly comes from TDD, but DbC can add little value as well. With TDD to test a component in isolation you have to exchange dependencies of this component with test doubles like mocks or stubs. Thus you need abstractions/interfaces for those dependencies which enforces DIP. Then with Dependency Injection you are able to inject a test double at runtime of a test. The influence of DbC is more subtle. DbC encourages the use of interfaces at whole by enforcing uniform behavior over all implementations of an interface. Thus the use of interfaces instead of concrete implementations in terms of DIP is encouraged as well.
  • LSP (Liskov Substitution Principle):
    TDD can’t help you here, but DbC adds great value. The LSP states that in class hierarchies it must be possible to treat a derived object as if it would be an object of the base class. Thus the specialized object must behave in the same way as the base class object. This principle of clear sub-classing is a basic part of DbC. Inheritors of a base class or implementors of an interface are not allowed to add new preconditions, but they can extend postconditions and invariants with additional contracts. Thus DbC guarantees uniform behavior in terms of the LSP.
  • CQS (Command-Query Separation):
    TDD doesn’t encourage you to do CQS. But with DbC you need to separate commands as pure methods and queries in order to use commands in contracts. Thus DbC leads to command-query separation which is a good thing since it keeps your API clean (SoC) and your components simple (KISS).


This and the last blog posts gave a comparison of DbC and TDD by taking several aspects into account: specification, design, documentation, code coupling, universality, expressiveness, correctness checking, code changes and influence on clean code principles. While writing this little series of blog posts things became much clearer to me. When starting with DbC some months ago I just thought: „Well, forget TDD, DbC with static checking is all what we need and what we should use„. But that was thought too short. TDD goes far beyond testing and writing unit tests. At its heart TDD is more about design, documentation and specification and it’s really valuable in those (and other) terms.

Both DbC and TDD have advantages and drawbacks and both act on their own terrains with interesting overlaps. And it’s absolutely not a mutual exclusive choice between both principles. However TDD and DbC should be used in conjunction to utilize the advantages of both principles. In fact there should be a clear TDD process that makes use of contracts. As the previous blog posts showed DbC can support TDD, but there’s no possibility to replace it in any way.

kick it on

Comparison: DbC and TDD – Part 3

This blog post is a continuation of the comparison between DbC and TDD that started with a dedicated look at code specification and covered other aspects in part 1 and part 2. It takes a look at further points and shows the characteristics (commonalities and differences) of TDD and DbC towards these aspects.


One of the most important differences between DbC and TDD is their different universality, because it influences expressiveness as well as verifiability of correctness.

A significant limitation (or better characteristic) of TDD is that tests are example-driven. With a normal manually written unit test you provide exemplaric input data and check for certain expected output values after the test run. Thus you have concrete pairs of input/output values to express a certain feature/behavior that you want to test. Since these values are only examples there has to be a process of finding relevant examples which can be very difficult. One step towards correctness is high code coverage. You should find examples that examine all paths of your code components. That can be a mess since the amount of possible code paths grows exponentially with the count of branches (if, switch/case, throw, …). But even if you find examples that give you 100% code coverage you cannot be sure that the component acts right for all possible input values. On the one side there could be hardware-dependent behavior (e.g. with arithmetic calculations) that leads to differences or exceptions (division-by-zero, underflow/overflow etc.). On the other side perhaps you get 100% code coverage for your components during the TDD process, but this doesn’t help much on integration with other code components or external systems that could act in complex ways. This problem goes beyond TDD. Thus unit tests in a TDD fashion are nice by their flexibility and simplicity, but they cannot give you full confidence. Solutions like Pex can help you here, but this is part of another story (that I hope to come up with in the near future).

DbC on the other side introduces universal contracts that must hold for every value that an object as part of a contract can take. That’s an important aspect to ensure correct behavior in all possible cases. Thus contracts have a higher value in terms of universality than tests (but they fall back in other terms).


The expressiveness of a component’s behavior and qualities as part of its specification is an important aspect since you want to be able to express arbitrary properties in a flexible and easy way. Universality is one part of expressiveness and has just been discussed. Now let’s look at expressiveness on a broader scope.

TDD has a high value on expressiveness besides the exemplaric nature of tests. You are free to define tests which express any desired behavior of a component that can be written in code. With TDD you have full flexibility, but you are also responsible to get this flexibility under your control (clear processes should be what you need). One aspect that goes beyond the scope of TDD is interaction/collaborative testing and integration testing. The TDD process implies the design of code components in isolation, but it doesn’t guide you in testing the interactions between components (and specification of behavior which relies on those interactions). TDD is about unit testing, but there is a universe beyond that.

Their universal nature makes contracts in terms of DbC a valuable tool. And moreover by extending the definition of a code element they improve the expressiveness of these code elements, what’s great e.g. for the role of interfaces and for intention revealing. But they have downsides as well. First they are tightly bound to a certain code element and are not able to express behavior that spans several components (e.g. workflows and classes interacting together). And second they have a lack of what I would call contentual expressiveness. With contracts you are able to define expectations with arbitrary boolean expressions and that’s a great thing. But it’s also a limitation. For example if you have an algorithm or complex business operation then it’s difficult to impossible to define all expected outcomes of this code as universal boolean postcondition. In fact this would lead to full functional specification which implies a duplication of the algorithm logic itself (in imperative programming) and this would make no sense! On the other side if you use example-driven tests you would not have a problem since you should know what values to expect on a certain input. Furthermore no side effects are allowed inside of a contract. Hence if you use a method to define a more complex expectation this method must be pure (= free of visible side effects). The background of this constraint is that contracts mustn’t influence the behavior of the core logic itself. It would be a mess if there would be a different behavior depending on the activation state (enabled/disabled) of contracts (e.g. for different build configurations). This has a limitation if you want to define certain qualitites with contracts like x=pop(push(x)) for a stack implementation, but it has advantages as well, since it leads to the enforcement of command-query separation by contracts.

Checking correctness

Of course you want to be able to express as many behaviors as possible to improve the specification of your code components. But expressiveness is not leading anywhere when it’s impossible to figure out if your components follow the defined specification. You must be able to stress your components against their specification in a reproducible way to ensure correct behavior!

With TDD correctness of the defined behavior (= tests) can be checked by actually running the tests and validating expected values against the actual values as outcome of a test run. The system-under-test is seen as blackbox and behavior correctness is tested by writing values to the input channels of the blackbox and observe the output channels for correct values. This could include techniques like stubbing or mocking for handling an object in isolation and for ensuring reproducible and verifiable state and behavior. This testability and reproducibility in conjunction with a well implemented test harness is important for continuously checking correctness of your code through regression testing. It’s invaluable when performing continuous integration and when code is changed, but this aspect will be covered in the next blog post. However the exemplaric nature of tests is a limitation for checking correctness which has been shown above when discussing universality.

At first DbC as principle doesn’t help you in terms of checking correctness. It introduces a fail-fast strategy (if a contract is not met, it’s a bug – so fail fast and hard, because the developer has to fix the bug), but how can you verify the correctness of your implementation? With DbC bugs should be found in the debugging step when developing code, thus by actually executing the code. And common solutions like Code Contracts for .NET come with a runtime checking component that checks the satisfaction of the defined contracts when running the code. But this solution has a serious shortcoming: It relies on the current execution context of your code and hence it takes the current values for checking the contracts. With this you get the same problems as with tests. Your contracts are stressed by example and even worse you have no possibility to reproducible check your contracts! Thus dynamic checking without the usage of tests makes no sense. However contracts are a great complement of tests. They specify the conditions that must apply in general and thus a test as client of a component can satisfy the preconditions and then validate postconditions or custom test behavior. Another interesting possibility to verify contracts is static checking. Code Contracts come with a static checker as well that verifies the defined contracts at compile-time without executing the code. On the contrary it actually inspects the code (gathers facts about it) and matches the facts as abstraction of the implementation against the defined contracts. This form of whitebox code inspection is done by the abstract interpretation algorithm (there are other solutions like Spec# that do real formal program verification). The advantage of static checking is that it’s able to find all possible contract violations, independent of any current values. But static checking is hard. On the one side it’s hard for the CPU to gather information about the code and to verify contracts. Hence static checking is very time-consumptive which is intolerable especially for bigger code bases. On the other side it’s hard for a developer to satisfy the static checker. To work properly static checking needs the existence of the right (!) contracts on all used components (e.g. external libraries) which is often not the case. And looking at the static checker from Code Contracts it seems to be too limited at the current development state. Many contracts cannot be verified or it’s too impractical to define contracts that satisfy the checker. Thus static checkers are a great idea to universally verify contracts, but especially in the .NET world the limitations of the checkers make them impractical for most projects. Hence a valid strategy for today is to write tests in conjunction with contracts and to validate postconditions and invariants with appropriate tests.

[To be continued…]

kick it on

Comparison: DbC and TDD – Part 2

This blog post is a continuation of the comparison and differentiation between DbC and TDD. Please take a look at part 1 which covers the design aspect (and shortly specification again which has been discussed in more detail here). Today’s post takes a look at documentation and code coupling and shows commonalities and differences of TDD and DbC towards these aspects.


One important thing for other developers to understand your code is documentation. Code comments are a first necessity here to basically explain what a code component is intended to do. But comments have the unpleasant habit to run out-of-sync with the real code if you are not carefully and consequently adapting them. Most of all if you write obligations or benefits into comments there will be no check if those requirements hold or if the real implementation matches them.

DbC with its contracts is a much better way to document those specification aspects. Contracts are coupled to the code and e.g. with Code Contracts you get static and runtime checking for them. This checked documentation makes DbC really powerful (if properly used) and avoids the asynchronicity between code and documentation. It shows developers how a component should be used, what requirements the client  has to fulfill and what he can expect in return. The client can rely on these specified qualities which improves the reusability of contracted code components. Furthermore there are possibilities to integrate Code Contracts into the Sandcastle documentation and for Visual Studio 2010 there will be an add-in that immediately shows defined contracts on a component as you develop against it. With that you get great MSDN-like documentation that contains the defined contracts as well as support for your development process when you use contracted code.

Tests in terms of TDD add another aspect of documentation. Due to their exemplary nature and their specification of an element’s behavior those tests are great to show a developer the intent of a code component and give him a guideline to its usage. Since tests can be run and validated in a reproducible way developers are able to rely on defined behaviors as well.

Together with documentation comes the aspect of intention revealing. And both TDD and DbC add some value here. Both express the developer’s intention with a certain component and show far beyond code comments and naming conventions what behavior a client can expect. Developers can use the component in these specified ways and don’t have to manually investigate the component’s implementation.

Code coupling

One drawback of TDD is the locational gap between the code implementation and the tests as specification and documentation source. For sure this has an advantage as well: the code logic isn’t polluted with the specification and thus it’s kept clean. But the disadvantages weigh heavier for me. If developers want to show how a component behaves they have to cross the gap and investigate the tests. This is difficult for developers who are not very familiar with TDD. Furthermore tests don’t give any support for client usage of a component. Of course they give usage examples, but developers can use and especially misuse a component in arbitrary ways. This can lead to serious problems (e.g. inconsistent states) if there are no other mechanisms to prohibit misusage.

DbC on the other side sets contracts directly on the implementation of a code component in place. Thus they have a declarative nature and extend the definition of a code component. Some realizations of DbC like Code Contracts in .NET have drawbacks since they set contracts imperatively into the code, but rewrite the code after compilation to set the contracts in the „right“ places. Thus Code Contracts break the uniformity principle (different semantics should be expressed through different syntax) and pollute the code logic in some way. Other realizations like the Eiffel language have contracts as keywords built into the language which makes a better choice in my opinion. Anyway contracts at the same place as the implementation avoids the drawbacks of a locational gap. And moreover DbC prevents misusage of a component. Contracts are dynamically checked at runtime or statically at compile time and fail early if requirements are not satisfied. That’s a very important concept because it expresses a clear behavior if something goes wrong (existence of a bug) and gives a clear contract for obligations and benefits that hold and are checked in client/supplier communication.

[To be continued…]

kick it on

Comparison: DbC and TDD – Part 1

Let’s come to another blog post in preparation of elaborating the synergy of DbC and TDD. My first blog post on this topic covered an initial discussion on specification of code elements. Thereby it has shown different characteristics of DbC and TDD in terms of code specification. Since specification is one really important aspect in comparison of DbC and TDD, it’s of course not the only one. Hence today’s blog post is a starting point for a more general comparison of DbC and TDD with some other important aspects. There are 3 more blog posts that I will come up with during the next weeks, forming a 4-part comparison series.

To say first, Test-Driven Development (TDD) and Design by Contract (DbC) have very similar aims. Both concepts want to improve software quality by providing a set of conceptual building blocks that allow you to prevent bugs before making them. Both have impact on the design or development process of software elements. But both have their own characteristics and are different in achieving the purpose of better software. It’s necessary to understand commonalities and differences in order to take advantage of both principles in conjunction.

Specification again…

The last blog post has already given a dedicated look at the specification aspect and how DbC and TDD can add some value. To summarize both principles extend the code-based specification in their own ways. TDD let’s you specify the expected behavior of a code element in an example-driven and reproducible way. It’s easy to use and allows the expression of any expected behavior. DbC on the other side sets universal contracts in place that extend the definition of a code element and are tightly coupled to it. It’s a great concept for narrowing the definition of a code element by defining additional physical constraints as preconditions, postconditions and invariants. By defining contracts on interfaces DbC strengthens the role of interfaces and enforces identical constraints/behavior over all implementations of an interface. However not every behavior can be expressed by contracts and they’re bound to a single code element. Thus they don’t lessen the position of tests, but can be seen as great complement.

Design aspect

Both DbC and TDD have impact on the design of an API. Well, there is a slight but important difference as the names imply: it’s Design by Contract, but Test-Driven Development. Thus with DbC (contract-first) on the one side you are encouraged to write your contracts as you design your components (at design phase), which perfectly fits with the idea of contracts as extension of a component’s definition. With TDD and the test-first principle on the other side you write a test which maps to a new feature and afterwards you directly implement the code to get the test to green state. Hence TDD is tightly coupled to the development phase in contrast to DbC, which seems to come first. In addition personally I wouldn’t fight a religious war on this naming. If you think of DbC as „Contract-First Development“ or „Development by Contract“ you would have the contract-first principle coupled to the development phase as well. The more important thing is to find a way to effectively use contracts in the development cycle. If you are an advocate of up-front design you would perhaps want to set your contracts at design phase. But if you intensively use TDD it would be difficult to go down this design phase road. However you would set your contracts at development phase in conjunction with the test-first principle. This leads to the question of an effective development model with TDD and DbC and that’s another important story…

But for now let’s come back to the impact of DbC and TDD to the design of an API. With TDD you write a new test for each new feature and then you bring this test to green by implementing some piece of logic. This is some form of Client-Driven Development. Your test is the client of your API and you call your methods from the client’s perspective (as a client would do). If the current API doesn’t fit your needs, you extend or modify it. Thus the resulting API is very focussed on the client’s needs and furthermore doesn’t contain code for unnecessary features, which is a great thing in terms of YAGNI. Another impact of TDD is that it leads to loosely coupled components. Tests in form of unit tests are very distinct and should be coupled to the tested component, but not far beyond that (other components that are called, e.g. data access). Thus there is a certain demand for loose coupling e.g. by DI.

With DbC and contracts on your components you have other impacts. Contracts clarify the definition and intent of your components. When you come up with contracts you strengthen your opinion about a component by setting contractual obligations and benefits. This leads to much cleaner components. Moreover your components will have fewer responsibilities (and thus a better cohesion) since it would be painful to write contracts for components with many different responsibilities. Thus DbC is great in terms of supporting the SRP and SoC. Another impact comes from the „limitation“ of contracts to support only pure methods as part of a contract. If you want to use class methods in contracts (e.g. invariants) of this class you have to keep those methods pure. This leads to the enforcement of command-query separation by contracts, which very often is a good thing in terms of comprehensibility and maintainability.

[To be continued…]

kick it on

Specification: By Code, Tests and Contracts

Currently I’m taking further investments in thinking about the synergy of Design by Contract (DbC) and Test-Driven Development (TDD). This process is partially driven by my interests in Code Contracts in .NET 4.0 and other current developments at Microsoft (e.g. Pex). The basic idea I’ve got in mind is to combine DbC and TDD to take best advantage of both principles in order to improve software quality on the one side and to create an efficient development process on the other side. My thoughts on this topic are not too strong at the moment, so feel free to start a discussion and tell me what you think.

Before I come to discuss the synergy of DbC and TDD it’s absolutely necessary in my opinion to understand the characteristics, commonalities and differences of both concepts. This first blog post drives in this direction by looking at a very important aspect of both concepts: the formal and functional specification of code. It’s a starting point for further discussions on this topic (a 4part comparison series follows). So let’s start…

Code-based specification

In essence, DbC and TDD are about specification of code elements, thus expressing the shape and behavior of components. Thereby they are extending the specification possibilities that are given by a programming language like C#. Of course such basic code-based specification is very important, since it allows you to express the overall behavior and constraints of your program. You write interfaces, classes with methods and properties, provide visibility and access constraints. Furthermore the programming language gives you possibilities like automatic boxing/unboxing, datatype safety, co-/contravariance and more, depending on the language that you use. Moreover the language compiler acts as safety net for you and ensures correct syntax.

Since such basic specification is necessary to define the code that should be executed, it has a lack of expressiveness regarding the intent of a developer and there is no way to verify correct semantics of a program with it. As an example interfaces define the basic contract in terms of method operations and data, but looking at C# a client of this interface does not see what the intent of a method is or which obligations he has to fulfill when calling a method or what state he can assume on return of a method. Furthermore interfaces can not guarantee uniform behavior across their implementations. TDD and DbC are there to overcome or at least decrease this lack of expressiveness at some points and to guarantee correct semantics.

Test-based specification

Let’s come to test-based specification using TDD (as well as BDD as „evolutional step“ of TDD). This is inevitably integrated in the TDD cycle. Every test written by a developer maps to a new feature he wants to implement. This kind of specification is functional and example-driven, since a developer defines by exemplary input/output pairs what output he expects as result of the test run under a certain input. With well-known techniques (stubs, mocks) he is able to run his tests in isolation, get reproducible test results and perform state and behavior verification.

Compared to code-based specification, test-based specification in a TDD manner is very valuable when it comes to expression of the behavior of a code element. It gives a set of tests that could at its extreme span the whole behavior of a code element. With their reproducibility the tests are indispensable when it comes to continuous integration to ensure correct behavior of modified code elements. Furthermore tests are a great source for other developers to show the intent of a developer for a method’s behavior and to give demonstration of the usage of a code element. There are other benefits and characteristics of TDD that will be discussed when comparing TDD and DbC altogether in subsequent blog posts.

An important aspect of test-based specification using TDD is that it’s done at a very granular level. For each new feature a test is written and if the present API doesn’t fit the needs, it will be extended or refactored. Thus TDD drives the API design as you go with your tests.

Contract-based specification

Another possibility for specifying code is contract-based specification in terms of DbC, thus defining preconditions and postconditions as method contract and invariants as class contract. With contracts you are able to define the basic obligations that a client must fulfill when calling a method as well as the benefits he gets in return. Furthermore invariants can be used to define basic constraints that ensure the consistency of a class. Thus with DbC a developer is able to define a formal contract for code that makes a clear statement of obligations and benefits in client/supplier communication (aka caller/callee). If a contract fails the behavior is clear as well: by failing fast the developer can be sure that there is a problem (bug) with his code and he has to fix it.

On a technical level there are several possibilities to define contracts. In Eiffel contracts are part of the programming language itself in contrast to Code Contracts that become part of the .NET framework. In any case contracts are directly bound to the code that they are specifying and express additional qualities of the code. Those qualities go beyond the code-based specification. In general contracts allow arbitrary boolean expressions what makes them a very powerful and flexible specification source. Nonetheless contracts only allow partial functional specification of a component. It can be very difficult or even impossible to define the complex behavior of a method (which methods is it calling, what business value does it have, what’s the concrete result for a concrete input, …) or to ensure certain qualities (e.g. infrastructure-related questions like „is an e-mail really sent?“) with contracts. Furthermore it’s impossible to use impure functions in contracts which would be necessary to express certain qualities of code (like expressing inverse functions: x = f-1(f(x)), if f or f-1 are impure). Test-based specification could be used here instead.

But let’s come back to the technical aspect: Contracts are wonderful animals in terms of extending the code-based specification by narrowing the definition of a code element and becoming part of the element’s signature. They can be used to define general conditions, e.g. physical constraints on parameters and return types. Thereby (for example with Code Contracts) the contracts can be inherited to sub-classes while respecting the Liskov substitution principle (LSP). Moreover contracts can be defined on interfaces and thus they are a valuable tool for expressing constraints and qualities of an interface that must be respected by every implementation. With that contracts are wonderfully strengthening the role and expressiveness of interfaces and complementing code-based specification at whole.

With the tight coupling to the code, contracts give immediate support for other developers how an API should be used. They express the developer’s intent (intention revealing) for his code elements, which leads to easier comprehension and usage of those components. They give some kind of checked documentation, which again greatly complements code-based specification and leads to fewer misusage of contracted components.

In contrast to test-based specification, contracts are employed at level of whole components by employing invariants to classes and pre-/postconditions to class methods. Moreover contracts lead to components with very few dependencies (promoting the SRP) since it’s difficult to write contracts for components with many responsibilities.

First conclusion

This blog post is intended to be a first preview of what I want to come up in the next time. It has given an overview of possibilities for specification of code elements with focus on test-based and contract-based specification in terms of TDD and DbC. It has shown some commonalities and qualities of both concepts. In conclusion TDD and DbC are both valuable in terms of the specification of code elements and in revealing the developer’s intent.

In my opinion it’s by no means a „one or the other“ choice. TDD and DbC act on their own terrains with their own benefits and drawbacks. There are overlaps, but in general they can naturally complement each other. It’s time to think about ways to leverage a conjunction of both concepts, isn’t it?

[To be continued…]

kick it on