> I disagree. IMO automatic testing is thousands of times better than > design by contract and Python has already all the support you need > (unittest, doctest, py.test, nose, ...)
In theory, anything you can verify with "design by contract" you can also verify with unittest and the rest. However, "design by contract" has a major practical advantage: if you have real (or simulated) inputs available, you don't need to write a test driver or generate test inputs for each class or function. All you need to do is to run your program with the real (or simulated) inputs, all the internal data that gets passed around between classes and functions gets generated as usual, and everything gets tested automatically. In other words, you are spared the potentially considerable effort of generating and storing samples of all the internal data that gets passed around internally. You may want to do unit tests also, of course. Separate unit tests will give you more control and allow you to test individual classes and functions using a wider variety of inputs. But if your design by contract is comprehensive (i.e., passing it guarantees correct functioning of your code), then your unit tests can simply make use of the tests already available in the design by contract. So you've done no extra work in setting up the design by contract anyway. Another significant advantage of "design by contract" is that the tests are all right there in your source code, where they are much less likely to get lost or ignored by subsequent programmers who need to maintain the code. Relying on separate units tests is a bit like relying on extended "comments" or design documents that are separate from the code. Yes, those are certainly useful, but they do not eliminate the need for comments in the code. -- http://mail.python.org/mailman/listinfo/python-list
