Its been a while I have ready Mcconnell’s “Code Complete“. Now I read it again in Hunt & Thomas’ “The Pragmatic Programmer“: Use assertions! Note: Not Unit Testing assertions, I mean Debug.Assert().
Following the SO questions When should I use Debug.Assert()? and When to use assertion over exceptions in domain classes assertions are useful for development, because “impossible” situations can be found quite fast. And it seems that they are commonly used. As far as I understood assertions, in C# they are often used for checking input variables for “impossible” values.
To keep unit tests concise and isolated as much as possible, I do feed classes and methods with nulls and “impossible” dummy input (like an empty string).
Such tests are explicitly documenting, that they don’t rely on some specific input. Note: I am practicing what Meszaros’ “xUnit Test Patterns” is describing as Minimal Fixture.
And that’s the point: If I would have an assertions guarding these inputs, they would blow up my unit tests.
I like the idea of Assertative Programming, but on the other hand I don’t need to force it. Currently I can’t think of any use for Debug.Assert(). Maybe there is something I miss? Do you have any suggestions, where they could be really useful? Maybe I just overestimate the usefulness of assertions? Or maybe my way of testing needs to be revisited?
Edit: Best practice for debug Asserts during Unit testing is very similar, but it does not answer the question which bothers me: Should I care about Debug.Assert() in C# if I test like I have described? If yes, in which situation are they really useful? In my current point of view such Unit Tests would make Debug.Assert() unnecessary.
Another point: If you really think that, this is a duplicate question, just post some comment.
In theory, you’re right – exhaustive testing makes asserts redundant. In theory. In parctice, they’re still useful for debugging your tests, and for catching attempts by future developers who might try to use interfaces not according to their intended semantics.
In short, they just serve a different purpose from unit tests. They’re there to catch mistakes that by their very nature aren’t going to be made when writing unit tests.
I would recommend keeping them, since they offer another level of protection from programmer mistakes.
They’re also a local error protection mechanism, whereas unit tests are external to the code being tested. It’s far easier to “inadvertently” disable unit tests when under pressure than it is to disable all the assertions and runtime checks in a piece of code.