4 ms·

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

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?

vlovich123 4y ago
Very similar but I suspect most people don’t use asserts properly so this is more of an opinionated approach that makes it more difficult to misuse.
renox 4y ago
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).
- unsafecast 4y ago
  You missed a backslash before your asterisks :)
gavinray 4y ago
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.
- MuffinFlavored 4y ago
  DbC?
  - andreareina 4y ago
    Design by Contract

vlovich123 4y ago

Very similar but I suspect most people don’t use asserts properly so this is more of an opinionated approach that makes it more difficult to misuse.

renox 4y ago

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).

unsafecast 4y ago
You missed a backslash before your asterisks :)

gavinray 4y ago

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.

MuffinFlavored 4y ago
DbC?
- andreareina 4y ago
  Design by Contract