Best practices for Design by Contract (DbC) and Test Driven Development [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

I'm interested in obtaining a concise recommendation on how best to use code contracts and tests in practise, across the board from development to production. I understand that both are different paradigms, both testing different things.

On a method level, a contract may specify the the parameters need to be of type STRING and have a minimum length of THREE CHARACTERS to pass. A unit test may ensure that for ANY given string that matches this, the output hash is correct (assuming that to be the role of the function).

Must a test exist to ensure that the contract fails? I understand that for a test to be valuable, it must be repeatable and thus are not good candidates for assisting in fuzzing. On the converse, DbC would allow for it.

Initially, I thought that a test could simply ensure the contract, but I'm assuming that this moves the contract outside of the definition of the method, and DbC is trying to enforce a tight coupling?

Similarly, are contracts actively enforced only during development? In production code, a build has no sign of the unit tests, but what about DbC? Are contracts "ignored" or are assertions allowed to blatantly fail in practise?

Is it true to say DbC does not exist in methods whose role is validation? For example, one would expect invalid inputs from the front end. I'm assuming DbC is defined strictly within the realms of where any input is assumed "clean".

Answer 1

I use DBC and unit tests for different things, along the lines you are reasoning.

I don't verify contracts using unit tests, instead I create a "bot" that simulates (fuzzy) user behavior and use that to try to trigger error conditions in my app. I find contracts to be really helpful especially in the cases where the number of permutations of input to my app is really large, since it in that case is very hard to get confidence only from unit tests.

I don't run my code in production with contracts enabled.