0

I have a .NET library, targeting .NET 4.5 which contains some

Debug.Assert (condition);

or even

Debug.Fail ("foo");

I then have UnitTests project (still .NET 4.5, nunit 2.6.2) referencing my library. When I'm running the tests, or Debug the tests, the execution doesn't stop when one of the assertion fail. The exception Debug.Assert() should throw is swallowed and ignored.

I'm running Xamarin Studio 4.2. the same projects behave as expected on Visual Studio.

The same thing happen if my library is build on Xamarin.iOS and I'm referencing it from a Xamarin.iOS app. The exception is printed on the console, but that's it.

All my builds are done in DEBUG obviously.

Is this a known bug, am I missing something, am I doing something wrong >

Stephane Delcroix
  • 16,134
  • 5
  • 57
  • 85
  • Side note: `Debug.Assert` are not exceptions, but rather notifications to logging/tracing listeners to do something... Generally pain to deal with (especially in case of VS behavior that you want to achieve)... I'm happy that someone configured unit test project to ignore them by default :) – Alexei Levenkov Nov 16 '13 at 08:07
  • 1
    Couple more links - this post discusses why you should not be testing asserts: http://stackoverflow.com/questions/4886790/is-there-a-way-how-to-continue-after-debug-assert-from-the-code, and here is my answer to fixing VS behavior to be a bit more test-friendly - http://stackoverflow.com/questions/5504183/what-do-i-have-to-do-so-that-assertions-wont-block-automated-tests-anymore/5504284#5504284 (which may help you to "re-enable" `Debug.Assert` for tests). – Alexei Levenkov Nov 16 '13 at 08:17
  • `Debug.Assert()` is known to behave indeterminable in many contexts. Even in Visual Studio, the expected message window might not pop up, for instance if the assertion happens on a background thread. Preferably use some logging instead. Or throw a real exception that will pop you to the debugger. – PMF Nov 16 '13 at 08:36
  • 1
    I'm using `Debug.Assert`s for what they are. I don't use them to test my logic in unit tests. I'm using them as safe guard in my business logic call, as loop invariants for example, and when it happens, it means the developer using the lib is at fault (so throwing is expected in DEBUG) but the lib can recover from that so it shouldn't throw in RELEASE. – Stephane Delcroix Nov 17 '13 at 12:23

1 Answers1

1

This is (was?) a known bug in Mono and I think it may have just recently been fixed, but it might not yet be in a released version of Mono (I'm not sure on that). I just recall Michael Hutchinson telling me that it's been fixed within the past few weeks.

My guess is that it will be fixed in Mono 3.2.5 or so.

jstedfast
  • 35,744
  • 5
  • 97
  • 110