On 01/28/2011 12:36 PM, bearophile wrote:
I think the problem here is that you are not using your D tools well enough yet:
- Preconditions allow you to save some tests in your unittests, because you
have less need to test many input boundary conditions.
- Postconditions are useful to save some code to test the correctness of the
results inside your unittests. You still need to put many tricky but correct
input conditions inside your unittests, but then the postcondition will test
that the outputs are inside the class of the correct outputs, and you will need
less unittest code to test that the results are exactly the expected ones in
some important situations.
Very intersting points, thank you.
- The missing "old" feature once somehow implemented allows to remove some
other unittests, because you don't need a unittest any more to test the output is
generally correct given a certain class of input.
What is this "old" feature?
Generally with unittesting you can't be sure to have covered all interesting
input-output cases (code coverage tools here help but don't solve the problem.
Fuzzytesting tools are able to cover other cases), while with DbC you can't be
sure your general rules about correct inputs, correct outputs (or even general
rules about what a correct input-output pair is) are accurate enough to catch
all bad situations and computations.
So generally DbC and unittests are better for different purposes, using them
both you are able to complement each other weak points, and to improve your D
coding.
Ditto.
I definitely need a "mental jump" to think in terms of DbC; nearly never use
it, simply don't think at it.
I also suggest to try to write contracts first and code later, sometimes it
helps.
Just what I sometimes do for tests ;-)
Denis
--
_________________
vita es estrany
spir.wikidot.com
