The B-Tree invariant example in the unit test seems like a bunch of assertions. Feels very similar to unit tests? Am I missing something?
Assert at runtime or assert at unit test time, it's assertions all the way down? Not sure the benefit of some weird @decortator-like syntax to achieve 5-10 lines of assertions?
Contracts and Invariants don't replace unit tests, they're complementary
This is the big mix up with DbC in general I think. Think of it more like sanity-tests and assertions that help ensure your program isn't in some haywire state.
A good example with the BTree is that the invariants ensure the properties are enforced at runtime, but you still need test to invoke those properties.
These sorts of invariants mix really well with property-style tests:
You write some declarative specification for a set of boundaries on inputs/outputs, and then subject your classes to the generated inputs. If your tests pass, then all your invariants have held and you know at the bare minimum, the data structures are doing what you intend them to do.
Above that you can do load-testing and subject the invariants to scale-factors.
If I remember well(), the idea between contracts is that they can be enabled at runtime, so very different from UT.
Also different from assertions in that 'class' invariants applies to every public method of the class.
: All I know about 'Design by Contract' I learned it in the (very good IMHO) book Object Oriented Software Construction by Bertrand Meyer (he made the Eiffel language).
Assert at runtime or assert at unit test time, it's assertions all the way down? Not sure the benefit of some weird @decortator-like syntax to achieve 5-10 lines of assertions?