May
09
2009

TDD & DbC @ DotRT

Last wednesday there was another Devnology event: the developers of the round table met at.. a rectangular one. Despite the out-of-place table, it was a very good meeting in any way that matters. I couldn’t shake of the feeling that the program didn’t fully work out as planned, but everybody was completely cool with it and the result was even better than planned. Discussions! And lots of it, of pretty high quality. See for yourself, as a picture says more than a thousand words..

After the event, Pieter-Joost van der Sande and I had a nice little off-time discussion about the interchangeability of Test-Driven Development and Design by Contract. PJ, correct me if I am wrong, but I remember you defending the viewpoint that DbC is an improvement over unit tests and consequently over TDD too. DbC is all a developer needs. đŸ™‚ Might be a bit of an exaggeration, but it comes close to what you said, right?

My viewpoint is more the other way around: TDD is more than unit testing alone and even unit tests are not a fully replaced by DbC. I see DbC more as a alternative to documentation. Where one would normally have to write the pre- and post conditions in documentation, he is now able to use formal descriptions of those conditions, that get checked by the compiler. Quite cool! However, what I have seen of Spec#, makes me wonder if it is not a little bit too early to use in C#. I noticed it was quite demanding of processor cycles. Maybe other implementations of DbC in C# are faster though. And I have never heard about performance problem of the technique in Erlang.

Ok, time to make my case to defend TDD. I will present the PRO’s of using TDD as technique first and than the PROs of Dbc, both compared to the other technique, where applicable. Questions of practicality of one or the other approach I will leave behind, because for all I know, those are all solvable.

PROs TDD

  1. TDD makes you focus on the interface of what you are developing first. This helps a developer design elegant interfaces that create as small an overhead as possible in the client code. I see no such mechanism in DbC.
  2. Unit tests test not only the contract of a method, but also its implementation. I think this is quite important.
  3. Automated unit tests give you a near-instantaneous overview of problems in the code, just as DbC gives you (compiler) errors.

PROs DbC

  1. DbC helps a developer use an API all the while. For unit tests to be useful to a client developer, he must have them (and not only the bin) and look into them.
  2. DbC helps a developer write less defensively. Argument checks and Exceptions are replaced by pre and post conditions and checked compile time.
  3. DbC enables you to write pre- and post conditions in a consitent and useful way. Considering you should write them any way, no time is lost. Writing unit tests is an investment of development time not directly won back. [I find this argument quite questionable, as a lot of API documentation that is written does not include pre- and post conditions, so it might not be as important as DbC proponents think. And writing tests has proven to be a method to improve quality of the code and reduce time spent debugging]

As you can see, the positive effects of TDD and DbC are not really matched by the other. So, I think TDD and DbC are not replacements of each other. There is some overlap. You might need less unit tests when using DbC too, because all the test cases concerning out-of-bounds arguments might be skipped. But in general I think they complement each other more than replace each other. DbC helps describe a method more than a name can and in a way that can be actually used to check for errors compile time. But in my view, you write documentation after the design settles. For code that is still changing a lot, documentation is just a drag on the refactoring process. TDD, writing (unit) tests first, focuses your attention on writing usable code, on writing a useable API and provides you with a set of unit tests at the same time. Of course, it also imposes some drag on refactoring, but less so than documentation, because you focus on the intent of a method / class, which should be less viable to change. That is, if you write good unit tests.

Moreover, I am not the only one who thinks TDD and DbC complement each other: the article about TDD on Wikipedia states the same thing. And here is an article stating the same, even creating a new style of development on it, named Agile Specification-driven development.

Written by Rick | Tags: , , , , |

3 Comments - Leave a comment »

  • Even the notorious Donald Knuth winked to provable correct code. A famous quote states:

    “Beware of bugs in the above code; I have only proved it correct, not tried it.”

     Comment by AndrĂ© Boonzaaijer — Sunday, 10 May 2009 om 09:26
  • Oh yes and of course my own opinion on this matter: http://whiletrue.nl/blog/?p=93 đŸ™‚

     Comment by AndrĂ© Boonzaaijer — Sunday, 10 May 2009 om 09:29
  • Nice quote. đŸ™‚

    I read your article and had a look at the test framework. For data-driven unit tests I can see this go a long way.

    By the way, I have been doing TDD in a statically typed language for a while now and it is quite acceptable to me, I must say. There is just a short while in which it doesn’t compile. And you cannot use IntelliSense. But that’s a very short time. Of course, SmallTalk is ideally suited for TDD, but most of the pro’s translate to other languages as well.

     Comment by Rick — Sunday, 10 May 2009 om 13:28

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes

Better Tag Cloud