I've been trying to get up to speed with unit testing in Windows Phone 7, and I have a basic test harness working, but when running the tests with the debugger attached, an Assert failure will cause VS to break at the exception:
From what I've read, I should be able to stop this behavior by disabling first chance exceptions. I tried unchecking User-unhandled from the Common Language Runtime Exceptions on the Debug->Exceptions dialog, as described in this blog post. This post was about enabling first chance exceptions, but I expected doing the opposite would disable them.
I tried adding the specific exception names as described in this blog post, and that also did not work:
Other details:
I'm using the Windows Phone SDK 7.1 Beta 2, published 6/29/2011
I'm using the updated Silverlight Unit Testing binaries for the Mango beta
I followed the first section of this cheat sheet to get the test harness running
I'm hoping that someone can point me in the right direction, or at least confirm that this does in fact work on their machine.
Ultimately, this isn't a big problem; I could start without debugging (CTRL+F5), and eventually, shouldn't hit this anyway since all the tests should pass, but it's annoying that I can't get it to run through without breaking into VS.
Have you tried this?
http://sgomez.blogspot.com/2009/12/how-to-disable-assert-dialogs-while.html
Add to your config file:
<system.diagnostics>
<assert assertuienabled="false"/>
</system.diagnostics>
Related
TLDR
When one of my applications executes _CrtDbgBreak() it just writes a .dmp file and exits. On any other application _CrtDbgBreak() causes the app.exe has stopped working -dialog where I can chose to break into my debugger (VS 2013).
This is my desired behavior.
Background
A few weeks ago I experimented with Windows Error Reporting to find out if/how the WER Dialog could be suppressed. Apparently I succeeded for my application and unfortunately I haven't found the way how to undo this.
In the meantime I have had to deal with a number of other things so that I no longer remember which steps I exactly took at the time. (Should have taken notes, I know.) Since it works for other applications, I am guessing a setting specific to my app needs to be reset.
I turned to the usual suspects on my machine but so far I haven't found anything:
HKCU\Software\Microsoft\Windows\Windows Error Reporting
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting
Policy Editor: Computer Configuration\Administrative Templates\Windows Components\Windows Error Reporting
Policy Editor: User Configuration\Administrative Templates\Windows Components\Windows Error Reporting
WER Service is running
I have even removed all occurrences of my executable's name from my entire registry but this hasn't made any difference. What else am I missing?
One possible reason is your app/exe is added to the WER's exclusion list. See 'ExcludedApplications' at https://learn.microsoft.com/en-us/windows/desktop/wer/wer-settings.
https://learn.microsoft.com/en-us/windows/desktop/api/Werapi/nf-werapi-weraddexcludedapplication
Check registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ExcludedApplications
If your app/exe name is found there, remove it.
Maybe you'd set the process error mode, like so
SetErrorMode(SEM_NOGPFAULTERRORBOX);
(see https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode)
[yes - the question is dated, but it's not marked as answered, and this alternative solution may help future readers]
My Android app has some slow running functionality. A unit test captures it perfectly. The unit test execution shows that it runs way slower than it should be.
Android Studio keeps offering me next to the run method a menu option: "Profile" instead of run. I select that option, but nothing different than run seems to happen. I expected Android Studio to open a window with the timing of all the method calls after the test completes.
I've searched Google and the Android site. Everything I find talks about profiling in Android Studio in general.
How do I profile an Android unit test? (What does that profile option really do?)
I had the same issue and I decided to investigate a solution because I was thinking that it couldn't be too hard. Boy was I wrong.
My original answer which was never posted contained some awkward fiddling around with Thread.sleep and manual timings and hitting the right button at the right time. This was replaced by a more elegant solution using the Debug API from within the code.
Using Android Studio 3.1.3 these were my steps:
I had to copy my actual unit test into androidTest (because I actually was interested in algorithmic complexity (and not time consumption) I found no way to actually profile inside Android Studio without an emulator. For performance tests this makes sense but in my case I wanted to ensure that even in complex scenarios my methods behave in a predictable fashion.)
To avoid the need of fiddling with with Thread.sleep and log output indicating a start/stop you can use combinations of Debug.startMethodTracing("File"); or Debug.startMethodTracingSampling() and Debug.stopMethodTracing(); or similar (See https://developer.android.com/studio/profile/generate-trace-logs). My code now looks like
#Test
public void Test_Something() throws Exception
{
Debug.startMethodTracing("Predict");
// DO YOUR CODE
Debug.stopMethodTracing();
}
When I now execute the profile I can obtain the .trace generated in the mentioned location on the device as stated in the link above:
(again read the linked page because you will need WRITE_EXTERNAL_STORAGE permission, which my app already had, so it wasn't that much of a hassle in my case.
Double clicking the trace opens it in Android Studio. Unlike stated at the link above I am currently unable to import such a trace in the profiler because either 3.1.3 lacks this function or I am unable to locate it.
Edit: After I upgraded to Android Studio 3.2 I now can indeed load and save sessions and display them in the Profiler. This has improved a lot. And interesting fact: When I opened the trace in Android Studio 3.1.3 I saw the hit count for methods (how often methods were called) and not their clock times. In the profiler on the other hand I was not yet able to find the call times but instead have access to wall clock times. Would be great if someone has a hint on how to display those too.
We just "upgraded" from Visual Studio 2008 to Visual Studio 2012. We updated our unit tests and now they pass when running them individually but when I try to Run All, I got the following error:
The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either
at the machine level or for process vstest.executionengine.appcontainer.x86.exe. Go to more details: [http://go.microsoft.com/fwlink/?linkid=232477][1]
So I went to the link and followed the instructions to add the registry key to enable local crash dumps. The error message then changed to:
The active Test Run was aborted because the execution process exited unexpectedly. Check the execution process logs for more information.
If the logs are not enabled, then enable the logs and try again.
Apparently it noticed the changes that I made in the registry to enable crash. However, when I looked in %LOCALAPPDATA%\CrashDumps, no files were being created.
If I run one test at a time (or even a few tests at a time), I can get them all to pass. The problem is only with Run All.
Has anyone else encountered similar problems? If so, how did you solve them?
Essentially the same question was asked on MSDN, but the answer was something like "click the link to the crash dump". That answer doesn't help me because I don't see any link to the crash dump and I am unable to get the crash dump to be generated.
This question on StackOverflow is also similar, and ended up resulting in a bug being logged on Microsoft Connect (which looks to be deferred for some reason), but my problem might be different because my code has nothing to do with "async tasks" (I don't think).
EDIT: The problem went away, seemingly on its own, but the problem was likely an exception that wasn't being caught in the unit test code, as some of the answers below suggest. However, I'm still confused as to why the problem only appeared with Run All, and not when running smaller groups of tests or Debug All.
I had the same problem, the tests failed for apparently no reason. Later I found that a buggy method was causing a StackOverflowException. When I fixed my bug, the VS bug disappeared.
Maybe it works most of the time because you don't run the faulty code.
The best workaround I have so far is to debug all. This is done via TEST -> Debug -> All Tests. It's obviously slower but it doesn't crash.
This can happen with certain errors, such as a stackoverflow. Presumably this is crashing the test runner and so it can't continue when it hits a test that causes the problem.
The solution, therefore, is to run all tests in debug (from the Test -> Debug menu) and Visual Studio will show errors like these.
For anyone else who may need this in future: My test runner was crashing when a console specific command (Environment.Exit(-1);) was executed via the unit test. Even running in debug mode would just crash - I could not get at a useful error message.
So my scenario is different to the main question scenario in that a) debug didn't work at all b) run all vs run individually made no difference. That is because my error scenario always arose but the stack overflows of the original question did not.
The bottom line: test runner is bad and will crash if it finds something it doesn't like. You need to manually isolate and work out what the Bad Thing™ is.
For someone else looking for this: I had some code that was calling System.Environment.Exit(123), and I was unaware of this. So check for any code that terminates the process.
I've just had the same problem. It turned out that was my code - there was an infinite loop of WCF service calls. In your case this might be something else. So my proposal is to either remember (logs in version control system?) or to figure out (by excluding different tests from run, e.g. with bisection method) which place in code leads to this behavior. And wuala! It's cause of the problem and at the same time bug in code.
UPDATE
As for questions in your EDIT. It could happen that running smaller groups of tests didn't reproduce the issue. In this case, given those groups included all tests, one can make an assumption that some tests interfere. Maybe some static data or fields in a test class?
As for running tests in debug mode - I'm not surprised. Visual Studio test runner behaves different in "Run" mode vs "Debug" one.
I had a similar problem except that it wasn't a stackoverflow exception. It was caused by my project under test using Entity Framework and the NUnit project not having references included to the EntityFramework and EntityFramework.SqlServer modules. Adding the references to Entity Framework modules fixed it.
Just had the same problem. Closing and reopening visual studio fixed it for me.
I am using google test in a C++ project. Some functions use assert() in order to check for invalid input parameters. I already read about Death-Tests (What are Google Test, Death Tests) and started using them in my test cases.
However, I wonder if there is a way to suppress the runtime errors caused by failing assertions. At this time each failing assertion creates a pop-up window I have to close everytime I run the tests. As my project grows, this behaviour increasingly disturbs the workflow in an unacceptable way and I tend to not test assert()-assertions any longer.
I know there are possibilities to disable assertions in general, but it seems more convenient to suppress the OS-generated warnings from inside the testing framework.
Ok, I found the solution myself: You have to select the test-style threadsafe. Just add the following line to your test code:
::testing::FLAGS_gtest_death_test_style = "threadsafe";
You can either do this for all tests in the test-binary or for affected tests only. The latter is faster. I got this from the updated FAQ: Googletest AdvancedGuide
Here's the scenario. I'm debugging my own app (C/C++) which is using some library developed by another team in the company. An assertion fails when my code generates some edge case. Its a pain because the assertion is not formulated correctly so the library function is working OK but I get all these interruptions where I just have to continue (lots as its in a loop) so I can get to the stuff I'm actually interested in. I have to use the debug version of the library when debugging for other reasons. The other team wont fix this till next release (hey, it works on our machine).
Can I tell the debugger to ignore the breakpoints asserted by this section of code (i.e. can it auto-continue for me).
If the code is triggering breakpoints on its own (by __debugbreak or int 3), you cannot use conditional breakpoints, as the breakpoints are not know to Visual Studio at all. However, you may be able to disable any such breakpoints you are not interested in by modifying the code from the debugger. Probably not what you want, because you need to repeat this in each debugging session, however still may be better than nothing. For more information read How to disable a programmatical breakpoint / assert?.
There's no good way to automatically ignore ASSERT() failures in a debug library. If that's the one you have to use, you're just going to have to convince the other team that this needs fixed now, or if you have the source for this library, you could fix or remove the assertions yourself just to get your work done in the meantime.
You can add an exception handler around the call(s) to the library, catch the EXCEPTION_BREAKPOINT exception and do nothing.
Example 2 in the following link seems to be what you want to do:
http://msdn.microsoft.com/en-us/library/ms681409(VS.85).aspx
You can use conditional breakpoints. Some links:
http://support.microsoft.com/kb/308469
http://dotnettipoftheday.org/tips/conditional_breakpoint.aspx