Ryan Ginstrom wrote: > I tried using DBC for a time in C++ (using a library with a clever > assembly-language hack). I personally found it neater having such code in > unit tests, but obviously, it's a matter of preference.
I agree that it ultimately boils down to preference, but as I tried to explain earlier, I don't think that unit tests are equivalent to DBC (or, as I referred to it earlier, "self-testing code"). Unit tests are not automatically executed when you run your application. You need to write the drivers and generate sample inputs to all the functions in your application, which can be very time-consuming. And if you think you can anticipate all the weird internal data that might come up in the execution of your application, then either your application is very simple or you are fooling yourself. With self-testing code, on the other hand, all you need to do is to get sample inputs to your application (not internal inputs to functions) and run the entire application. That is much simpler and more comprehensive than unit testing. Again, I recognize that it doesn't necessarily replace unit testing completely. For one thing, unit testing can test for specific outputs for specific inputs, whereas you wouldn't want to clutter your actual code with such specific cases. For example, a unit test for a sorting function could provide a specific input and test for a specific output, but you probably wouldn't want to clutter your code with such a case. The self-tests in your code would be more for general tests. PEP 316 provides an excellent of comprehensive tests for a sorting function. If you pass those tests, you can be sure your function worked correctly. -- http://mail.python.org/mailman/listinfo/python-list
