Defensive To Proactive – Ignoring Debug.Assert

The Google testing blog has a nice post on how asserts inside the production code are not that good for testability. And the case they present is very true. Defensive programming is good when you don’t have tests.

If the code comes to a Debug.Assert(x != null) you’ll be presented with a nice message box. It puts real brakes on automation. But with Isolator, you don’t need to care about that.

You can use:


And that’s it. All the Debug.Assert calls are now ignored, and you can test the real production code.

  • Morgado

    I don’t think faking the Debug.Assert or Trace.Assert is a good idea. When an assertion fails, it means that something happened that shouldn’t have.

    You can supress the messages in the configuration file (/configuration/system.diagnostics/assert/@assertuienabled=false). I use it both in testing and in production.

    I also use a custom trace listener to make the test fail if an assertion fails:

  • Gil Zilberfeld


    While the intent of asserting within the code is to make sure the code works, a)it reduces readability and b) it may not cover all scenarios. In (b) it may be that you want to test a scenario that the production code won’t let you because of the incomplete assert (refer to the Google test blog original entry for a great example).

    As for disabling asserts through configuration – that’s an all or nothing solution. You may want this per test.

  • Brian

    I’ve always found Debug.Assert a powder keg anyway.

    Nothing like having your web site stopped because of a Debug.Assert in your page code behind!

  • Gil Zilberfeld

    Not dismissing it completely, but I see it as a “yesterday tool”, or rather a crutch.

    With unit test tools today, and automatic unit testing methodology, I think it’s obsolete. It’s the remaining artifacts that we need to get rid off.