design-by-contract

After posting this question and reading that one I realized that it is very important to know if a method is supposed to return null, or if this is considered an error condition and an exceptions should be thrown. There also is a nice discussion when to return ‘null’ or throw exception . I'm writing a method and I already know if I want to return null or throw an exception, what is the best way to express my decision, in other words, to document my contract? Some ways I can think of: Write it down in the specs / the documentation (will anyone read it?) Make it part of the method name (as I

A few years ago, I did a survey of DbC packages for Java, and I wasn't wholly satisfied with any of them. Unfortunately I didn't keep good notes on my findings, and I assume things have changed. Would anybody care to compare and contrast different DbC packages for Java? There is a nice overview on WikiPedia about Design by Contract , at the end there is a section regarding languages with third party support libraries , which includes a nice serie of Java libraries. Most of these Java libraries are based on Java Assertions. In the case you only need Precondition Checking there is also a

You may think this question is like this question asked on StackOverflow earlier. But I am trying to look at things differently. In TDD, we write tests that include different conditions, criteria, verification code. If a class passes all these tests we are good to go. It is a way of making sure that the class actually does what it's supposed to do and nothing else. If you follow Bertrand Meyers ' book Object Oriented Software Construction word by word, the class itself has internal and external contracts, so that it only does what its supposed to do and nothing else. No external tests required

I wanted to try a little design by contract in my latest C# application and wanted to have syntax akin to: public string Foo() { set { Assert.IsNotNull(value); Assert.IsTrue(value.Contains("bar")); _foo = value; } } I know I can get static methods like this from a unit test framework, but I wanted to know if something like this was already built-in to the language or if there was already some kind of framework floating around. I can write my own Assert functions, just don't want to reinvent the wheel. Luke Quinane C# 4.0 Code Contracts Microsoft has released a library for design by contract in

I'm working on improving our group's development process, and I'm considering how best to implement Design By Contract with Test-Driven Development. It seems the two techniques have a lot of overlap, and I was wondering if anyone had some insight on the following (related) questions: Isn't it against the DRY principle to have TDD and DbC unless you're using some kind of code generator to generate the unit tests based on contracts? Otherwise, you have to maintain the contract in two places (the test and the contract itself), or am I missing something? To what extent does TDD make DbC redundant?

Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation ? Note: I am not talking about comments within the code By "value limits", I mean: does a parameter can support a null value (or an empty String, or...) ? does a 'return value' can be null or is guaranteed to never be null (or can be "empty", or...) ? Sample: What I often see (without having access to source code) is: /** * Get all readers name for this current Report. <br /> * <b>Warning</b>The Report must have been published first. *

Is there any way to indicate to ReSharper that a null reference won't occur because of Design-by-Contract Requires checking? For example, the following code will raise the warning ( Possible 'null' assignment to entity marked with 'NotNull' attribute ) in ReSharper on lines 7 and 8: private Dictionary<string, string> _Lookup = new Dictionary<string, string>(); public void Foo(string s) { Contract.Requires(!String.IsNullOrEmpty(s)); if (_Lookup.ContainsKey(s)) _Lookup.Remove(s); } What is really odd is that if you remove the Contract.Requires(...) line, the ReSharper message goes away. Update I