Add Debugger.Break() to Debug.Assert

[BrennanConroy]

Running tests via command line, or running a program (not testing) will crash the process if a Debug.Assert condition fails, and it will pause the debugger if running under one. Both of these behaviors are what I expect and want. However, when running tests via VS testing the Debug.Assert just throws an exception. Which depending on the test could silently pass.

I see #2309 which is when this behavior changed. And while I still think the process should crash when not running under the debugger, I think at a minimum it should break under the debugger so you can see that one of your debug checks is failing.

See https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Diagnostics/DebugProvider.Unix.cs,18 for example.

[nohwnd]

I would love this to be implemented as exception and also a "note" to the test framework that the test failed even if the exception is swallowed. In retrospect the design implemented was not the best.

[nohwnd]

but this needs to be implemented on each test framework level, so we cannot do anything about it here, except for adding an option to disable the Assert failure captuing.

[halter73]

@nohwnd I see you marked this as up-for-grabs. Would you accept a PR that calls Debugger.Break() before TestHostTraceListener throws the DebugAssertException?

I agree that it would be best to "note" to the test framework that the test failed even if the exception is swallowed, but breaking when a debugger is already attached seems like an improvement with no real downsides. It would not crash the test host process or have any impact at all unless a debugger was already attached to the test host. I cannot imagine not wanting the debugger to stop in that instance.

I don't want perfect to be the enemy of good.

[nohwnd]

I cannot imagine not wanting the debugger to stop in that instance.

I can imagine it. There is failing assertion I am trying to investigate (by debugging) because I broke some basic assumption. I run tests in debug and and I hit the break 100 times.

Instead if I want debugger to stop in the assert failure I could just configure it to stop on DebugAssertException.

[halter73]

I'm really suprised there is pushback on this. These are debug builds, you can always remove the assert or use a release build.

If the same assembly was loaded by just about anything other than the VS test runner, the debugger would break in this scenario. If people didn't prefer that, why don't people complain when the debugger hits a break 100 times when their assert fails in a normal web or cli app?

Instead if I want debugger to stop in the assert failure I could just configure it to stop on DebugAssertException.

No one knows to do that! The whole problem is that people expect assertions to break an attached debugger without any special configuration just like they would in any other project.

When the debugger doesn't break, they're not going to think to stop on DebugAssertExceptions. They're going to assume no assertions have failed.

[nohwnd]

When the debugger doesn't break, they're not going to think to stop on DebugAssertExceptions. They're going to assume no assertions have failed.

That is why I wanted to have the assertion handling code to tell that to the test framework, so it fails the test in all circumstances, not just when you have debugger attached. And it also won't block your run when having interactive session on CI, or kill the whole test process when you don't have interactive session.