[epdlxjmonad]

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]

I 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

[epdlxjmonad]

Yes, 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/

[cuchoi]

Aren't these examples of unit tests?

[MaxBarraclough]

No, as they're runtime asserts baked into the code itself, rather than existing elsewhere.