Contract-Driven Development

Discussions

News: Contract-Driven Development

  1. Contract-Driven Development (24 messages)

    Bill Venners has been interviewing Bertrand Meyer, and in the latest portion of the interview they discuss Contract-Driven Development and compare it to Test Driven Development.

    Bertrand, who is known for his work on Eiffel, explains why he thinks contracts are the way to go.

    Excerpt

    Bertrand Meyer: "A test checks one case. A contract describes the abstract specification for all cases. Test-driven development is an interesting idea, but I think the way to go is to derive the tests from the contracts.

    I think there are two kinds of people interested in test-driven development. First, there are people who are very happy not to have to write a specification. If that's what you hope to get from Extreme Programming (XP), I don't think you'll get much improvement. But then there are people who are more seriously applying the idea of test-driven development, the way at least I would consider applying it, where the tests are really systematic. I haven't had the opportunity to talk to, for example, Kent Beck about this, but I hope he would agree that the right form of test-driven development is where the tests are systematic. And the best way I know to derive a systematic test is from contracts, because they're much more general and abstract. You can derive the specific from the general. You cannot really infer the general from the specific."


    Read Bertrand Meyer on Contract-Driven Development

    Earlier parts of the interview on:

    Design by Contract

    The Demand for Software Quality

    Threaded Messages (24)

  2. Contract-Driven Development[ Go to top ]

    It's interesting insn't it they are two subtely different and not neccesarily contradictory paradigms.

    I use iContract regularly and find it very helpful in terms of both documenting contractual restraints and enforcing them. Though I would recommend avoiding iContract tests or at least using a subset of them in production as they can be quite heavy weight.

    I have found it to take up no more than 5% extra of my time to write and maintain these tests and they always force me into thinking more about the code I'm writing. They also provide anyone looking at the code clear indication of the assumptions I have made (eg parameter a is never null and b is always positive).

    Long live design by contract.
  3. not in conflict[ Go to top ]

    TDD and CDD are not in conflict and work
    well together. TDD only tests the unit
    and doesn't test at runtime. Contracts
    test at runtime and test in an integrated
    environment, where most difficult problems
    occur. Both are useful. If either camp
    says their approach makes the other camp's
    approach useless then this is religion
    talking, not developers trying to get
    a system to work.
  4. Size of system using iContract[ Go to top ]

    Neil, quick question about the iContract implementation -- how big (number of classes) is the system where you've employed iContract. It seems you've made the two TDD and CDD work together and I was wondering if you elaborate on its success and what some of the problems might be in introducing into an existing, potentially large, codebase (as opposed to introducing it in a new system).
  5. Size of system using iContract[ Go to top ]

    Hi Shahid

    I've used it in segments of a moderatley large system, the overall system is about 100K NCSS (non-commented source statements) which probably equates to about 250K lines of Java. I have only used it in components of the system; probably around 10K lines at a go.

    My observations are:

    * It compliments test driven development very well.
    * Don't use with EJBs (major problems there). Just exclude them from instrumentation.
    * You can spend time fighting with iContract as a tool but not too much and the gains outway the difficulty.
    * I wouldn't use the instrumented code in a system that needs performance because you may wish to include preconditions that apply a condition to every member of a collection.
    * If you are designing by contract, ie one team is working behind an interface and another team are coding to the interface. Then it is invaluable.
    * You feel a lot more confident about your code.

    Oh and if I implied they were contradictory my apologies that was not intended we certainly use them together.
  6. Contract-Driven Development[ Go to top ]

    I started a discussion a year ago about this topic at http://groups.yahoo.com/group/junit

    I think that either TDD or CDD is obsolete. Of course one can buy two cars and drive them. But if he only needs one car, the other car is luxury. So I don't think its a religious debate. Its a matter of focusing on a single technique and mastering it instead of "focusing" on two techniques, and not becoming a master in any of the two.

    Personally I like the Design by Contract approach a little bit more than the JUnit approach. Its more intuitive for me. The side effect of Design by Contract is, that it does not improve the code like JUnit tests does. If one writes JUnit tests, he is forced to use its design. Then he detects more design design flaws than if he wouldn't write a JUnit test.

    I think it makes no sense to mix the two testing technologies. One has to be brave and choose that what he thinks is the lesser of two evils.
  7. Re: Contract-Driven Development[ Go to top ]

    I think that either TDD or CDD is obsolete. Of course one can buy two cars and drive them. But if he only needs one car, the other car is luxury. So I don't think its a religious debate. Its a matter of focusing on a single technique and mastering it instead of "focusing" on two techniques, and not becoming a master in any of the two.

    I think that's a bad analogy. While both have the same goal (writing bug-free software), their different approaches mean that there are different - and complementary - benefits that come from using each. Sticking with cars, a better analogy IMO would be that CDD is the seatbelt and TDD is the airbag. You're safer for having either of them, but safer still with both.

    Personally I like the Design by Contract approach a little bit more than the JUnit approach. Its more intuitive for me. The side effect of Design by Contract is, that it does not improve the code like JUnit tests does. If one writes JUnit tests, he is forced to use its design. Then he detects more design design flaws than if he wouldn't write a JUnit test.

    I think it makes no sense to mix the two testing technologies. One has to be brave and choose that what he thinks is the lesser of two evils.

    I don't follow your logic here. You point out that CDD is more intuitive for you and that TDD improves your code, but then say it makes no sense to mix them? It sounds to me like you've actually given a fairly strong argument <em>for</em> mixing them!
  8. Did I get you right, that you dont't see TDD as the "code ONE test, then code and test, then repeat"-cycle but see TDD as writing tests before coding? If this is so, how can you write tests without knowing the contract? IMO I need to know the contract to find the right equivalence groups to code my tests. I would feel lost, if I wouldn't know the contract. However, checking the contract during project runtime (test and if possible live system) helps me find areas, where I missed to test an equivalence group or where I have an error in my tests.
  9. BTW where can you get iContract from?

    I found: http://www.reliable-systems.com/tools/iContract/iContract.htm

    but this web site appears to no longer exist

    is it still being maintained?

    Cheers,
    Richard
  10. TDD and CDD - A Fine Match[ Go to top ]

    I think that either TDD or CDD is obsolete. Of course one can buy two cars and drive them. But if he only needs one car, the other car is luxury. So I don't think its a religious debate. Its a matter of focusing on a single technique and mastering it instead of "focusing" on two techniques, and not becoming a master in any of the two.

    Contracts and tests themselves are not in conflict - whether you have contracts
    or not, you still need to test.

    As to the question of the methodologies - CDD and TDD are in
    conflict, but only on a technicality - because CDD, in pure form, is really a
    design-first approach. However, with a little pragmatism, it is possible to
    combine the approaches.

    To combine CDD and TDD, you would drive contract creation by aiming at breaking
    the existing contract structure. A simple example: Imagine a method getAge(Date
    birthday). You may have a precondition "age >= 0", but no precondition. You then
    pass in getAge(someTimeNextCentury) and see the test break due to postcondition
    failure, as the method returns age -95, or maybe it throws some exception. This
    would then drive a new contract - a precondition for date before now. Or maybe
    it would drive a change in design - getAge(Date now, Date birthday). So you
    would adjust the test and re-implement accordingly.

    Far from being in conflict, CDD and TDD are actually a very good match. Among other objectives, both approaches facilitate literate programming - they each enable more specification detail to be embedded directly in executable code. Contracts can simplify tests by bringing certain assertions into the actual tested code. Furthermore, for unit testing, preconditions help define what's fair game, while invariants and postconditions provide clues as to how to prove the code, i.e. one way to drive tests is to see if these can be broken.
  11. Am I missing something here?[ Go to top ]

    After reading the article/interview, I get the impression that Bertrand is suggesting that in using a TDD approach one never puts any real effort into abstraction, generalisation or simply just “design” in general. Am I missing something here? Do I not understand TDD or CDD or both?

    I never heard Kent Beck, or anyone else make any such claim – maybe I just wasn’t listening. My understanding of TDD is that the design is put right through the process of refactoring i.e. this is when you abstract and generalise. True, your initial focus isn’t on the internal “design” of the unit but more on getting the interface right and getting the tests to pass as quickly as possible by whatever means necessary. A working test isn’t the finish line though – refactor (abstract, generalise, design), refactor, refactor and keep those test working and then go through the loop again.

    “A test checks one case. A contract describes the abstract specification for all cases. Test-driven development is an interesting idea, but I think the way to go is to derive the tests from the contracts.”

    That makes no sense to me either – “A test”. Fair enough, one test is pretty much useless; I’ll give him that. As they say in these parts – “One swallow never made a summer”. However, “Many tests” is useful, and to me constitute “a contract”. Maybe I’m taking the guy too literally.

    TDD Vs CDD?? Maybe I’m wrong again, but sounds to me like the main difference is the initial steps in either process:

    • TDD: You are initially focusing on just getting a test working to fulfil one “term of the contract” and leaving the real design until a little later (minutes – or you’re doing it wrong).

    • CDD: You are focusing on the design of the unit from the outset. Yeah??

    How could any approach realistically suggest that no thought be put into design?
  12. Contract-Driven Development[ Go to top ]

    is there some sample code available?
  13. Okay time to get shot to threads :-)

    /**
    * A factory methods that returns a singleton instance of DisplayDocumentType.
    *
    * @param documentId is the shortName of the description_code from the
    * DISPLAY_DOCUMENT table
    *
    * @return a DisplayDocumentType object of the type specified by documentId
    *
    * @pre typeMap.get(documentId) instanceof DisplayDocumentType
    * @pre exists DisplayDocumentType dt inarray types |
    * dt.shortName.equals(documentId)
    * @post return.shortName.equals(documentId)
    * @post return.casesRequired.equals(CasesRequired.ALL) ||
    * return.casesRequired.equals(CasesRequired.ACTIVE)
    */
    public static DisplayDocumentType getDisplayDocumentType(final String documentId)
    {
    DisplayDocumentType type = (DisplayDocumentType) typeMap.get(documentId);

    return type;
    }


    The above example is a random code snippet that uses iContract.

    The conditions match my assumptions and assertions that:

    * The object we will pull out of the type map are of the type DisplayDocumentType. Otherwise the cast will fail. (ASSUMPTION)
    * That the string identifier is one of the posible document types and is therefore in the map (the map is just a convenient way of accessing them they are originally an array). (ASSUMPTION)
    * That the returned documents short name is the same of the documentId. (ASSERTION)
    * That the cases required flag on the returned value is one of two possibilities. (ASSERTION)



    Please note that there is no validation outside of the preconditions because this is not an API method and therefore is part of a single unit of code which controls the inputs to these methods. Therefore the pre/post conditions just match my assumptions and assertions.

    DISCLAIMER: I am no expert on these matters I've just provided sample code so that Erik and Shahid can see how I personally have used it. The above code is not flame retardent ;-)
  14. Contract-Driven Development[ Go to top ]

    For any software developement there are four most important points to rememeber for successful delivery:
    1. Understand the business
    2. Engage actual users and management for review in short intervals.
    3. Communicate properly acroos all share holders.
    4. Use exteme testing.

    After thats it doesn't matter much, which xxxxx-Driven development used.
  15. Contract-Driven Development[ Go to top ]

    4. Use exteme testing.

    Thats the point. It can be done with TDD or CDD.

    I would like to add a point to your list. 5. Have the know how to implement the requirements. Because if you or your team lacks know how, the design will be bad or wrong and the project is likely to fail. And 6. Use productive tools, technologies and frameworks. We use a framework which kills our productiveness. But we must use it, because the IT boss decided it.
  16. Contract-Driven Development[ Go to top ]

    <quote>
    6. Use productive tools, technologies and frameworks. We use a framework which kills our productiveness. But we must use it, because the IT boss decided it.
    </quote>

    That is a nice comment. Having worked with people who claim that frameworks kill their productivity, I came to the conclusion that most of the time, its plainly untrue.

    While there might be some frameworks around, that are actually not fit for the job, beta, no simply not match etc., most of the time people do not take time to exploit the frameworks and learn the available frameworks properly to make efficient and effective use of it. I've heard stuff like "WebLogic/Oracle/IntelliJ (HearHear)/Emacs/C++/WebSphere/Java/Swing" kills our productivy to often that I basically go nuts when I hear it.

    BTW: Personally, I think that CDD is far superior than TDD for the precise reason that a test can only test thus far. Also, I would doubt TDD enables productivity if I think of the huge amount of data specific tests that need to written and of support classes to run decent tests without the backend systems available.. What it does (for me) is it reduces errors and verifies designs, which is not bad either though.

    Regards, Karl
  17. Contract-Driven Development[ Go to top ]

    5. Have the know how to implement the requirements. Because if you or your >>team lacks know how, the design will be bad or wrong and the project is likely >>to fail.
    Well that defintely helps especially during deployment time where you need to put training and UAT together. But still not main factor.

    6. Use productive tools, technologies and frameworks. We use a framework >>which kills our productiveness.

    Productive tools technologies and frameworks can help you upto one point, but never saw main factor for success of a project.

    I have seen big projects delivered successfully, developed in horriffic language (Visual Basic)with horrific coding stanards. Whole project was run with business knowledge of key senior developers and communication.
  18. Share Holders?[ Go to top ]

    3. Communicate properly acroos all share holders.

    Do you really mean share holders? That's new to me ;-)
  19. Share Holders?[ Go to top ]

    Sorry I mean stakeholders.
  20. I like the concept of design by contract (pre-conditions, post-conditions, invariants etc), but I struggle to find a good/appropriate approach to handling a violation of a contract.

    The idea of terminating the entire application due to a contract violation, as Bertrand mentions, is unacceptible in the majority of production applications. Having it in development and not in production is also a potentially hazardous approach (different dev/test app to production app).

    So, what is the best approach to handling contract violations, for a "fault tollerant" application.

    Is it to log the violation (alarm to operations), and then throw a runtime (unchecked) exception to be handled at the highest level...

    What are peoples thoughts and experience on this?

    Cheers,
    Richard
  21. With iContract as an example you can choose which exception to throw.

    I would however suggest that if you have some code that expects a positive integer and gets a negative one that you've got problems and you want to abort that code ASAP.

    It is better to leave bad code than allow the system to enter an undefined state. Take for example a banking application. If you add a deposit to your account and because of a bug the amount became a negative amount would you:

    a) be happy to have money deducted from your a/c.
    b) be happy that the deposit was aborted and the teller was notified immediately.

    (Please no glib c) options ...)

    I don't think it'sabout making the system fall in a heap when a condition is broken it's just about getting out of the current algorithm. It's the systems responsibility to then do something with the exception (roll back transactions alert the user etc.).
  22. Yes, I agree... this is what i meant by throwing a runtime (unchecked) exception to the highest level (i.e. rollback transaction etc). Which it sounds is what you can do with iContract.

    Does it impose much of an overhead?

    Do you still have extensive test suites? use JUnit etc?

    How well has it worked for you?

    Will have a look at it.

    Cheers,
    Richard
  23. Does it impose much of an overhead?
    It can, it inserts almost literal conversions to java of your expressions, so I'm sure you can see the potential there. But hey you can switch it off for releases and still have gained a lot through the entire development/system test cycle.

    Do you still have extensive test suites? use JUnit etc?
    Not extensive, but that's because I'm new to Unit tests and am learning the habit still.

    How well has it worked for you?
    I feel better about my code, I feel I've thought things through more and I find the code that has preconditions to be very stable (especially with the extra unit test confidence added). The confidence thing is kinda nice!

    Will have a look at it.
    Don't be put off by the fact that iContract is no longer maintained, I have used it for nearly a year without problems. The injected code is based on comments anyway so you can discontinue iContract at any time.

    I am always looking for better Design By Contract tools to add conditional assertions to my code. I'm sure with JDK 1.5 we'll see a good tool. Maybe the Groovy guys have thought about this also?
  24. Looking for a copy of iContract.[ Go to top ]

    Hi,Friends:

       I am now looking for a copy of iContract,but it seems that the home of iContract,the www.reliable-systems.com is not accessable(I've visited the website for several times but the only message shown was page not found:-(

    so if you have a copy of iContract,
    please send one to me,ok?

    my email address is :
    songqicpp at vip dot sina dot com

    with best wishes

    SongQi
  25. Looking for a copy of iContract too[ Go to top ]

    Hi,Friends: I am now looking for a copy of iContract,but it seems that the home of iContract,the www.reliable-systems.com is not accessable(I've visited the website for several times but the only message shown was page not found:-(so if you have a copy of iContract,please send one to me,ok?
    Me too! Please!

    Thanks

    Sylvain Cote
    pc.sylvain.cote@sympatico.ca