Unit tests in VS2010 (solution in release mode) - unit-testing

I am trying to run my unit tests (Test->Debug->Tests in current solution) in VS 2010.
The solution is built in Release mode. When I try to do that, VS is crashing.
Do you have any ideas?
Cheers

I guess the problem lies with the test code. Test code is crashing and bringing down the VS IDE too.
See while debugging, the tests are run in-proc and therefore because of any exception in test code the VS would crash too.
I would suggest that you set the "Break on Common language runtime exceptions" (Goto Debug -> Exceptions menu), and then debug the tests. That way you could hunt the exception in your test code.

Related

Only in unit test projects

Is this a new feature of VS 2017 that every time I am trying to debug a unit test, and point the cursor at a variable to inspect, VS freezes at first, then throw up this:
And if I hit F10 after this window finally goes away in 10-20 seconds, VS throws up this:
Is this a new normal and expected behavior, or I am missing any settings?
1) Please try to disable the option "Enable property Evaluation and other implicit function calls" under Tools->Options->Debugging->General.
2) Delete all of the breakpoints, reset the one that you want and debug again.
3) Another workaround could be to enable the option: "Use Managed Compatibility Mode" under Tools -> Options -> Debugging -> General, but it will disable Edit and Continue. Reference: Visual Studio 2015 update 3 crashing after "Getting DataTip text..."
4) Btw, the latest update of VS 2017 is 15.5.3, you may also try to update to it.
And of course, you could post the unit test code sample if it’s possible, since I could not reproduce this issue with unit test project in VS2017.

Throwin std::exception causes VS 2013 unit testing module crash

I've created unit test project for my C++ application in Visual Studio 2013. Unfortunately, it does not correctly handles exceptions during test: If i run test that just does following:
throw std::runtime_exception("hello!");
I see Windows "application has stopped working" box telling me that vstest.executionengine.exe has crashed. Meanwhile, Test Explorer in visual studio shows that this test has passed without errors.
Visual studio itself reports that "active test" was aborted, and error is unexpected. Reffers to https://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx but there is absolutely no useful information on that page about my problem.
How to properly terminate test execution in C++?
Solution
Ensure that all your tests can run at one time, because that's how unit tests work in VS2013 (Run All i mean)
Ensure that you have no assert(..) calls, use Assert class provided by header CppUnitTestAssert.h
Try removing I/O from your test code, for example, try using Logger class provided by header CppUnitTestLogger.h instead of your own implementation
Use command TESTS > Debug > Debug all tests to run all tests in debug mode, you will definetely find reason of your crashes.
More information
Reason of crashes
I think it is how assertion worked in my code, maybe it's abort(). This caused something unexpected in hosting process.

Is it possible to run a unit test in debug mode?

I've fixed a null reference problem. Now when I run the test related to that class, it fails. I'd like to know whether is possible to run a test in debug mode so I'll know why I am getting the exception?
The test was written by some else, it's calling a method, as part of the setup, with a lot of logic in it. I'd like to step in to see how values are being returned.
Thank for helping.
It is indeed possible, using the NUnit Test Adapter for Visual Studio 2012.
Also, just so you're aware: failed assertions will throw exceptions, causing the debugger to break execution. You can adjust your configuration to work around this, as described in this thread:
Debugging in VS2012 with NUnit without throwing exceptions?
You can also use ReSharper, which makes it pretty easy. Or, you can just go into the properties for your DLL project that has the test in it and make the test runner you are using the exe that runs when you run the project.
Right click the project in the solution explorer, select "Properties" from the menu, go to the "Debug" tab, click the "Start external program" radio button then set the project as the active project and run in debug mode.

Visual Studio C++ exception... weirdness

I have a Qt application that I compile in release configuration, run, and then perform operation X in the program. Everything runs fine.
I then compile it in debug configuration, run without debugging (so CTRL+F5), perform operation X in the program. Everything still runs dandy fine.
But when I try to run the debug configuration with debugging (so just F5) and then perform operation X, Visual Studio breaks in with a message that an exception has been thrown... in a completely unrelated part of the program (code being executed is far from the site where VS breaks, in the QHash template)... and then VS hangs and I have to kill it with the Task Manager. I can repeat this ad infinitum, and it always freaks out the same way.
Boost::exception is used for the exceptions. VS is 2008, SP1. Qt is 4.6.2, using the precompiled VS binaries from the Qt site.
Does anyone have a clue what is going on?
Visual Studio has a feature called "first chance exception handling" where, when running attached to the debugger, you can have the debugger break when exceptions of certain types are thrown.
You can change these settings by going to Debug -> Exceptions (Ctrl+Alt+E) and (un)checking the appropriate checkboxes.
When it breaks you should get a message in the Output window indicating what exception was thrown.
If you have _HAS_ITERATOR_DEBUGGING enabled (it is enabled by default in debug builds), it can cause a lot of iterator errors to throw exceptions instead of performing operations that would cause access violations. That's the only thing I can think of off the top of my head that would cause an exception to occur "randomly."

Debugging unit tests with resharper

I've just started using resharper and I found a very annoying thing about it. When debugging a unit test, I try to step-into (F11) a method, but visual studio complains that source code is not available. The problem is that resharper is wrapping method calls with its own classes. Of course I can put a braeakpoint further in my source, but this is very annoying. Do you know if there´s a solution for this? By the way, I'm using NUnit to write my tests
Thanks
Federico
After some playing around I managed to recreate this on my setup (Xunit.net in resharper, visual studio 2008)... The steps I took to recreate this are:
Set the dll that contains the tests as the startup project (I know you don't need to do this, was just trying to get it to fail)
Put a breakpoint in the unit test
Push F11 (the shortcut key for 'step into' in my configuration)
This complains 'Cannot start test project 'RowanBeach.Crm.Domain.Test' because the project does not contain any tests.'
Run the 'Debug Unit Tests' command from the Resharper menu (I have this bound to a key combination on my machine)
This displays the 'No source code available...' message
Of course that's not how you should start unit tests from resharper! :) If that's what you were doing (or something similar), try this instead:
Don't bother setting the dll as the startup project - it doesn't need to be
build or rebuild the dll that contains the tests
set the breakpoint
Put the cursor somewhere in the source code for the unit test you want to debug to set it as the 'current context' unit test
Run the 'Debug Unit Tests' command from the Resharper menu (You might want to bind this to a key combination if you haven't already)
Hopefully, that should work
What type of tests are you running - NUnit? MS Test? Something else?
I've never found it difficult to debug tests using R# - just put a breakpoint in your test and go. What method are you trying to step into? I've generally not tried to step into the NUnit methods themselves (assertions etc) but stepping into your own code should be okay.
If you can come up with a quick example, I'd be happy to try it myself.