But how do you test the recovery path if the invariant is violated in production code? You literally can’t write a test for that code path…

▲

josephg 3 hours ago | parent [-]

There is no recovery. When an invariant is violated, the system is in a corrupted state. Usually the only sensible thing to do is crash.

If there's a known bug in a program, you can try and write recovery code to work around it. But its almost always better to just fix the bug. Small, simple, correct programs are better than large, complex, buggy programs.

▲

addaon 3 hours ago | parent [-]

> Usually the only sensible thing to do is crash.

Correct. But how are you testing that you successfully crash in this case, instead of corrupting on-disk data stores or propagating bad data? That needs a test.

▲

josephg an hour ago | parent [-]

> Correct. But how are you testing that you successfully crash

In a language like rust, failed assertions panic. And panics generally aren't "caught".

> instead of corrupting on-disk data stores

If your code interacts with the filesystem or the network, you never know when a network cable will be cut or power will go out anyway. You're always going to need testing for inconvenient crashes.

IMO, the best way to do this is by stubbing out the filesystem and then using randomised testing to verify that no matter what the program does, it can still successfully open any written (or partially written) data. Its not easy to write tests like that, but if you actually want a reliable system they're worth their weight in gold.

	▲	addaon an hour ago \| parent [-]
		> In a language like rust, failed assertions panic. And panics generally aren't "caught". This thread was discussing debug_assert, where the assertions are compiled out in release code.