This is the first part of the critiques which I have started on IT based process and on the Idiots seating above you.
Lets start with the comments from the links below and than will put my analysis at the end..
Comment on Code Coverage from the famous blogger..
Monday, March 31, 2008 12:41:42 PM (Pacific Standard Time, UTC-08:00)
I know this is unfashionable, and maybe just plain wrong.... but personally I have an aversion to debug assertions. Some reasons I don't like them:
Why use them instead of exceptions?
If using them for performance improvement for the release build, then I'd challenge first of all whether this isn't just a form of premature optimization - and I'd guess usually with no data to prove that this exception code would actually have anything other than a trivial performance impact.
Next, a question... why would you wish an assertion *not* be thrown in the release build? Of course exception code would still be present in the release build, but assertions aren't. Since an assertion should only check for conditions which indicate an unexpected condition, given performance isn't an issue, why wouldn't you want the system to fail-fast once the system is known to be in an unexpected state? (As Rumsfeld would put it ... 'We have a known unknown!')
One statement which was made in this podcast was something along the lines of 'nothing forces a bug to be fixed quicker than a failing assertion'.
I'd challenge this as a differentiator between assertions and exceptions. If exception handling is used correctly, code should only catch exceptions which it can handle, and which do not indicate unexpected conditions. Unexpected (and therefore irrecoverable) exceptions should not be caught and should be allowed to propogate, thus causing the system to fail-fast. If the application is coded correctly, the bottom of the call stack will have an exception handler which performs appropriate error handling prior to termination - usually logging or displaying the error.
I also find that assertions are overused, particularly, I've seen code which seems to wrap most method calls with assertions for post-conditions.
I can understand this (somewhat) if the code being called is third-party code, but if this is internal code then shouldn't this assertion instead be in a unit test? Testing post-conditions through the use of an assertion inside code whose primary purpose has nothing to do with the assertion (it's purpose isn't to test the called method) I would argue is hit-and-miss.
In addition, if you place post-condition tests in unit-test code, it has the advantage that it can be maintained centrally along with the unit which is being tested. Developers of client code, can determine already checked post-conditions by looking at the unit tests. Littering client code with post-condition tests, results in redundant replicated tests, and cluttered code which (IMO) is difficult to read.
Another particular usage of assertions which I personally discourage is the use of redundant assertions - a frequent example - asserting a post-condition for a call, that a reference is non-null, where the very next line de-references the reference.... I've seen this quite often, and my reaction is why do this? The de-reference operation will result in the generation of a NullReferenceException. It's redundant code which I'd argue obfuscates the algorithm.
One use I can see for assertions is to assert a post-condition for a routine, within the routine. Particularly if the routine has a complex algorithm. Even here, though, wouldn't a unit test be a better form for this?
One thing I have wondered about a little, is if an IDE option where provided to 'hide' assertions, or perhaps color them in a lighter color to the surrounding code would help in limiting their affect on readability by making them less obtrusive.
I'd love to hear what you think on this Scott.
People have to say a lot positive about How unit testing improves productivity at below link