4 ms·
When writing code, we often think "according to the design of our system, this condition must be true at this point of execution.” Examples are: 1. The argumen
by epdlxjmonad 6y ago
When writing code, we often think "according to the design of our system, this condition must be true at this point of execution.” Examples are:
1. The argument x must not be 0.
2. The variable x must smaller than the variable y.
3. The list foo must be non-empty.
4. The variable x should have value 'Success' if it had value 'Try' in the beginning of the function call.
These 'invariants', or assertions, can be extremely useful for testing the correctness of the code. Put simply, if an invariant is violated (during unit test, integration tests, or system tests), it indicates that either the design or the implementation is wrong. An article on testing methodology would be more appealing if it had some discussion on exploiting invariants/assertions.
- AdieuToLogic 6y agoI believe "Design by Contract"[0], or "DbC", is the concept you are describing. In the Wiki page Notes and External Links sections there are some good resources IMHO. 0 - https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract
- epdlxjmonad 6y agoYes, closely related, but invariants can appear anywhere in the code (like loop invariants), and are less restrictive than pre-conditions and post-conditions which must appear in the beginning and end of methods. So, invariants are more about testing than design. Arguably, invariants are especially powerful in testing distributed systems: 0 - https://www.datamonad.com/post/2020-02-19-testing-mr3/ https://www.datamonad.com/post/2020-02-19-testing-mr3/
- cuchoi 6y agoAren't these examples of unit tests?
- MaxBarraclough 6y agoNo, as they're runtime asserts baked into the code itself, rather than existing elsewhere.