Best practice for debug Asserts during Unit testing

Question

Does heavy use of unit tests discourage the use of debug asserts? It seems like a debug assert firing in the code under test implies the unit test shouldn\'t exist or the d

Answer 1

You should keep your debug asserts, even with unit tests in place.

The problem here is not differentiating between Errors and Problems.

If a function checks its arguments which are erroneous, it should not result in a debug assertion. Instead it should return an error value back. It was an Error to call the function with wrong parameters.

If a function is passed correct data, but cannot operate properly due to the runtime has run out of memory, then the code should issue a debug assert due to this Problem. That an example of fundamental assumptions which if they don't hold, "all bets are off", so you must terminate.

In your case, do write the unit test that supplies erroneous values as arguments. It should expect an error return value (or similar). Getting an assert? -- refactor the code to produce an error instead.

Note a bug-free problem can still trigger asserts; e.g. the hardware could break. In your question, you mentioned integration testing; indeed, asserting against incorrectly composed integrated systems is assert territory; e.g. incompatible library version loaded.

Note, the reason for "debug"-asserts is a trade-off between being diligent/safe and being fast/small.