Hi, did you know that there's already a long established notion of a software contract? I.e.
Design by contract (or DbC).
With DbC, contracts are actually part of the code, not secondary constructs like unit tests. Contracts and unit tests are different, 'orthogonal' ways of verifying code. Contracts can be enabled/disabled at run time, and you wouldn't test the contract as such, though you could have tests that exercise typical workflows and contract violations would show up as exceptions being raised.
Also contracts in this sense are not meant to validate data, but to verify an object API is working as agreed.
Some modules that support DbC: Class::Contract, MooseX::Contract.
