Constraints and Contract programming

Constraint programming is not very inspiring, while Design by contract gives more food for thought.

My impression is that:

a) constraints are ENORMOUSLY valuable as a part of the Business Rules enforcement

b) they are normally understated in the code and scattered everywhere (XSD, SQL Constraints, Java Code...)

c) constraint exercising is normally not enough covered by Unit Tests

d) DbC testing as exercised by the Unit Tests is not guaranteed to be active in production, hence it doesn't give us the benefit of validations in real life environment.
Why Unit Test should explicitly code logic which belongs to the Business Domain? These Rules/Constraints should be incorporated in the Business Logic (vs the test logic).... the test logic should be reduced to setting up scenarios which exercise those rules, and let the rules fail themselves.

Here http://c4j.sourceforge.net/ a nice and simple example of DbC in Java (most links are broken though :o( ).
It shows clearly what a pre_condition, post_condition and invariant is.