Tests remain in 'pending' state forever - visual-studio-2010

In Visual Studio Pro 2010 I cannot run unit tests. They just show a result of "Pending" in the "Test Results" window.
For simplicity I created an empty solution, and added a new C# test project and clicked "Run All Tests in Solution". The "Test Results" window shows, with the default "TestMethod1" test showing, but then nothing happens and the status says "Test run in progress" forever. From there, clicking the stop button changes the status to "Test run stopping..." forever.
After poking around a bit, I found in process explorer that devenv launches QtAgent32 - but neither uses any CPU.
This is the first time I've tried to run unit tests in Visual Studio. Is there a necessary setup step I need to perform to run tests?

Install Service Pack 1 for the fix.
I eventually found a duplicate also providing the answer here: VS 2010 Ultimate web performance test always pending

I know this is a little bit to late. I got the same problem and in my case it was the controller full disk the created the truble

Related

Automated Tests in Visual Studios 2013 being unpredictable?

I am writing Coded UI tests within Visual studios 2013 to automated some different tests for my company. As I was writing these tests, I was testing them and ensuring that they were working correctly (which they were). After leaving one day, and coming back into work the next, I noticed that my tests were not working as expected (as they were when i left that day). I am working on a local copy of the automated tests (so that rules out someone else breaking it) and the code version that I am testing of our software hasn't changed.
What I noticed was going wrong, was that whenever I would double click on an item (say a menu to open a part of a program) the double click would not register. If I record multiple times, recording different clicks (instead of just a double click), I can get the window to pop through automation eventually. But this is only convenient when creating new tests.
Has anyone ever noticed this happening and have a solution?
Thanks!
Interestingly enough.... I found the issue. Turns out that I guess I changed my mouse settings inside of windows, turning down the double click speed. This was what was causing the double click not to register inside of the application....
Hope it helps anyone with this problem in the future

Where is the 'Tests Output Pane'?

Unexpected error detected. Check the Tests Output Pane for details.
Where is the 'Tests Output Pane'? I can't find it anywhere in Visual Studio. I found 'Test Explorer' but it doesn't show any details.
In the output window there is combobox "show output from". Choose Tests as shown here
The message really should be this
Unexpected error detected. Check the Output Window for details which can be found in the Show output from: section. Then select the Tests drop down to read the actual error.
Why the Confusion?
For the Tests window is, buried, in the output window. That window acts as the main window that shows the textual Build information; and hides the test result info in another dropdown.
So in the OutputWindow select Tests after a run.
Go to the view tab at the top of your screen, and select output.
If you're looking for the actual issue, for me it was:
vstest.discoveryengine.exe and
vstest.executionengine.exe
Open up Task Manager, go to Processes tab, right-click and End Process. Restart Visual Studio.
For me killing vstest.console.exe and vstest.discoveryengine.exe processes did the trick. No need to restart visual studio.
from the output section, a Combobox will appear and you will find there build, debug similarly tests too
enter image description here
In case this helps anyone. All my test cases vanished from the Test Explorer (VS 2019 Pro v16.5.4) and I noticed the inconspicuous message in the status bar - unexpected error detected. Check the Tests Output Pane for details.
Restarting Visual Studio did not help. Restarting as administrator did not help too.
I followed #Ben-Power into Task Manager and found at least 5 occurrences of vstest.console.exe processes running.
Killed all and opened Visual Studio again. Test Explorer loaded all tests as expected.
In case this helps anyone... I had same problem with the TINY HIDDEN error message on the bar on the bottom of Visual Studio:
Unexpected error detected. Check the Tests Output Pane for details.
After the info in previous answers helped me find the Tests Output Pane...
The error message I found indicated that VS was trying to run "Release" version of tests, even though VS was set to select "Debug". VS could not find the "Release" test assembly, because it had not been built!
I had been switching between "Release" and "Debug" previously. VS must have bug that does not handle switching properly all of the time.
SOLULTION: Restart Visual Studio.
After restarting, Test Explorer picked up the "Debug" setting -- and used "Debug" version of the test assembly.
So for me , I resolved it by just deleting the root folder on this path.
C:\Windows\Microsoft.NET\Frameworks64\v4.0.30319\Temporary ASP.NET Files\root
Just delete this root folder & you should be good to go :)
Change Terminal from show output from:

Debug at design time

I have a bug at design time described here, but I don't get to make Visual Studio debug at design time.
To debug at design time you need to go
to project properties on the debug tab
hit start external program and
navigate to where devenv.exe is.
On the command line arguments place the path to your project
includning the project file name:
SomeProject.vbproj
OK
Set a break point in the main program
and then hit play to open a new VS
instance
Here "then hit play to open a new VS instance" is unclear. What kind of play should I hit (Start Debugging)?
and it will load your project but you
will be debugging the project you
started it from so the code will break
even at design time.
As best I can tell, the answer to this question is really simple: The "Play" button that the instructions you found refers to is equivalent to the "Start Debugging" command. I'm not sure who wrote those instructions, because calling it the "Play button" is a truly terrible choice.
There's a walkthrough available on MSDN that's probably clearer.

NUnit with VS 2010 is no longer stopping at breakpoints

The answer to this has got to be simple, but I sure don't see it.
I'm working on an MVC2 project under VS2010, with Unit tests written in NUnit.
I debug the tests (and code) by starting the NUnit GUI, then clicking Debug -> Attach To Process in VS, and attaching to nunit-agent.
This has all worked fine for some time.
I added one additional test for a bug that I discovered this morning, and suddenly, my breakpoints are not being hit. NUnit just runs merrily along and says the test passes (which it shouldn't, since I haven't fixed the bug yet), without ever stopping at the breakpoint I have set on the very first executable line in the test method.
I've looked at everything I can think of, including rebooting the machine, and I can't figure out what has changed. (FWIW, the test project is configured to run under .NET 3.5, and I'm running NUnit 2.5.4. I have added the 4.0 "supportedRuntime" flag and "loadFromRemoteResources" flag to the section of nunit.exe.config, and I have also tried attaching to nunit.exe instead of nunit-agent.exe. Note that I am NOT getting the disabled breakpoint buttons with the "source code cannot be loaded" messages. The breakpoints are the standard red ball, they just never get hit.)
The answer was indeed simple.
Somewhere along the line, I had been using VS2010 to debug Script code by attaching to the browser. When you attach to a process in the debugger, you have to tell it what kind of code you are debugging, and debugging script code is incompatible with debugging managed code, so it turns off Managed code. Apparently VS remembers your last selection.
So when I attempted to attach to N-Unit, it was selecting Script as the type of code that I wanted to debug, and I didn't notice. All I had to do was select the drop down box in the "Attach to process" dialog box, and check managed code.
Thanks to Paul Laudeman in his CodeBetter Blog
Try attaching to the nunit-agent.exe process. That worked for me.

breakpoint will not currently be hit, why not?

Sometimes I get the message that the breakpoint will not be hit, and no symbols will be loaded.
The red icon in vs.net changes color, and the debug mode just doesn't work.
what is the reason for this?
You may be running your project in Release mode. If so, then switch to Debug mode
From Visual studio debugging issue with files of the same name by Philip Carney
Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.
Stop debugging (press red square icon) in Visual Studio
Clean Solution
Build Solution
Tools > Attach to Process (or start with debugging)
Start the program that you're attaching to, and run it such that your code will get hit
If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit
If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint
for manage code only - theres a good answer for this problem on the following site:
http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
for native + managed code - in the startup solution properties-> Debug tab
make sure that "enable unmanaged code debugging" check box is checked
After trying several suggested fixes for this I did the following to get it working.
Right Clicked my Project in the Solution Explorer and selected "Properties".
Went to the "Web" section and made sure "Start Action" was set to "Current Page".
Spent 3 1/2 hours on that... I'm going to go get a drink now.
I resolved this problem by selecting Automatic:Native Code for the "Attach to" field in "Attach To Process" form
Next to the "Debug/Release" dropdown list, there is another one with "Any CPU/Configuration Manager...". Click "Configuration Manager...", and you will see some of your projects might be in Release mode. Change all of them to Debug.
This can happen if the symbol fiels are different from the assembly (remote debugging), or when there is no "direct path", so the assembly hasent been load, but might be loaded using reflection and loading of the required assembly at run time.
This can also happen if the debugger is not attached to the process for whatever reason. If it's the case, you can always go to Debug - Attach to Process... and choose the right process. Your breakpoints should return to normal once VS determines it can hit them.
What does it say when you hover the mouse over the disabled breakpoint? It will usually tell you the problem. My favorite is the old 'source code is out of date', especially when I'm debugging a DLL. Another favorite is when the file you're looking at isn't the one you're debugging (a copy in another folder?). If it's a case where you can breakpoint a caller routine, but not the callee, stepping into the callee will force VS to open the 'proper' source file and you'll be able to set breakpoints. Confusing, I usually swear at VS at this point, it seems to help.
I had the same problem. Which I know is normally if the build versions are different, and something isn't matching up. I cleaned my project, rebuilt it, and then deployed and that got everything back in-sync.
I do not like to play with knives but the only thing that worked for me involved editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
I have tested with both deployed application and service, what I have found out that If the deployed code is different than a code in visual studio then breakpoint will not hit. Even small changes will affect and the breakpoint will not hit. So, It is better to debug the same version which is there on vs code and also in deploy application or service.
To fix this I had to re-create the virtual directory. I'm using Asp.Net 4.7 Framework and IIS Express. Went to Web project > property page > Web tab > clicked the "Create Virtual Directory" button next to Project Url textbox.
I forgot I had clicked this button in my "Main" branch, but then had switched to my "Sprint" branch. It kept running the "Main" code until I clicked "Create Virtual Directory" on my "Sprint" branch.
For me it was giving this because I haven't started the relevant project at start of application , it worked after I added project run on start

Resources