I think this is a known issue of NCrunch:
https://twitter.com/ONE7...uses/159648603021918209

I came across it this week though when we added some unit tests that were intended to test failure paths. Now each time that the tests are run I keep getting the Debug.Assert windows that you would get when running the application itself.

I would suggest to either filter out Debug.Assert messages or give us an option to do so under preferences.

I'm using NCrunch for Visual Studio 2012 version 1.42.0.12

To reproduce: Create a method with a Debug.Assert message. Create a unit test that fails said Debug.Assert message. Now a popup window with the Debug.Assert warning will show up each time NCrunch re-runs the tests.

You may have luck configuring the UI behavior via system.diagnostics configuration in e.g. a config file (see http://msdn.microsoft.co...s/library/ty5e4c4h.aspx ).

However, what you as developer need to consider is what you expect to happen when an assertion fails. Is this part of the code you are testing so the test should pass or do you want a test to fail if an assertion fails.
One way to handle this is to globally replace an assertion failure with an exception for tests (still use assertions in code but intercept them them e.g. via a trace listener), and in those scenarios you want to "ignore" assertion failures you use a custom listener, or customize behavior of current, to not throw an exception during an assertion failure.

*Edit: Regarding the UI dialogs themselves, I don't think this is NCrunch specific. I have experienced the same behavior with other test runners (e.g. ReSharper).

Hi LP -

Thanks for the detailed explanation. This really helps a lot with understanding the reasoning behind why your codebase works the way it does, and the constraints of the environment you're working in. I'm not sure if I can implement a direct solution in NCrunch that is specific to this problem (as I feel your situation is very specialised), but I will try to explain my reasoning behind this and hopefully I can inspire some more thought about other approaches to solving this problem.

On a technical level, this problem can be solved in NCrunch by mutating the input source code during processing by the NCrunch engine, or by manipulating the assembly output in NCrunch's build process (in a similar way as NCrunch adds instrumentation for profiling code coverage and performance). There are, however, some drawbacks to this:

- The behaviour would need to be conditional on a configuration setting, as I'm not entirely convinced that all users would want it. This would mean yet another configuration setting to add to the existing forest of configuration settings, making the tool harder to learn and understand
- There would be a performance penalty for needing to inspect the code to make the alterations to the Debug.Assert statements, which would become noticeable for large projects
- It further moves the code running within NCrunch's environment out of alignment with normal code behaviour, which can create unexpected situations that may be difficult for people to analyse (i.e. its 'magic')

As an alternative, there are few things I can suggest that may either mitigate or completely solve this problem for you:

- Set the Use build configuration setting for the project containing Debug.Assert statements to 'RELEASE' (or your own equivalent of a release build configuration name). This will force NCrunch to build the project in release mode, thus neglecting to compile the Debug.Assert statements. NCrunch will automatically introduce overrides into your build process to allow it to continue to analyse code coverage and performance data.

- Add #IF !NCRUNCH compiler conditional statements around the Debug.Assert calls. This will force NCrunch to ignore them at build time. Hopefully your team members won't delete these if they find them. A tidy way could be to wrap the call to Debug.Assert with something else, then place the compiler condition in the wrapper method. If you don't have many of these calls around and they are introduced infrequently, this may be the easiest solution.

- Speak with your team members about the usage of Debug.Assert in regards to automated testing. The problems you experience with this statement may go well beyond just NCrunch, as it effectively makes it impossible to have unattended test runs (i.e. running your tests over lunch, or on a build server). You may find that an accumulated number of these statements quickly brings any form of automated testing to a standstill, forcing you to forever sit around and click 'Ignore' again and again.

I hope this helps!


Cheers,

Remco

Changing the NCrunch configuration to Release is an acceptable solution for me. This is something I can do in my machine without affecting anybody else. I changed my configuration in my local and the Debug.Assert statements are no longer showing up so this issue has now been resolved on my end.



I addressed your suggestion briefly in my previous post. This was the next best solution. It was still not ideal in my case because there might be reasons why you want to have the .NET assertion popup when running a unit test manually (which I understand is also why NCrunch doesn't disable this in the first place). In any case, I was not trying to make an argument of whether popup assertions are good or needed but rather whether the user should be given the choice of suppressing them for continuous tests in NCrunch while still keeping them for everything else.



We do have unattended test runs in TeamCity and they were not affected by the Debug.Assert statements.

Thank you again for your replies,

-LP