I have recently attempted to upgrade a solution from VS2010 to VS2012, and as part of that I have introduced the new .runsettings file to generate code coverage results.
In order to specify the run settings file I have had to un-select the .testsettings file that was working in VS2010. As soon as I do this and run my tests, a large number of them start to fail because the CollectionViewSource.GetDefaultView method returns null instead of the expected default view.
If I re-select the old .testsettings file then my tests all pass, but the code coverage settings are incorrect.
Has anyone else experienced similar problems with the upgrade?
I worked out what the problem was: one of the unit tests was manually restarting the Dispatcher as part of some cleanup, and that worked fine in VS2010 but not in VS2012.
I guess this is pretty specific to the one solution, but it might provide a clue to anyone that finds this.
Related
I know that sounds strange but that is how it is)
I'm using MSTest to run my unit tests.
Using VS2013 + ReSharper 8.1 + some dll projects in C#.
I'm calling some API functions, that is why I need VS to running as Administrator or those calls will fail.
The problem is:
For some reason folder TestResults is empty.
While tests are running and not completed, I can see a new folder (User_Comp YYYY-mm-dd HH-MM-ss) created inside, with all test outputs, but once tests are completed this folder is deleted, so TestResults are empty.
I've checked my project Options->Web Performance Test Tools->Test Execution->Limit number of old Test Results is set to 25.
I've tried to disable ReSharper UnitTesting + disabled support for MSTests, NUnit and JS, but problem still exists.
When VS is started under normal account (not Administrator)
In this case folder "TestResults\User_Comp YYYY-mm-dd HH-MM-ss" is not deleted after test. Of course in this case some of my tests are failing.
I've set full access for each user to folder "TestResults" but still results are removed.
Looks that VS is using 0 as limit for Test Results.
Did anyone face this problem?
Test results are removed when all tests pass.
If any is failed, results are not removed.
Have you tried to add a *.testsettingsfile to your Test project in Visual Studio?
Have a look at https://msdn.microsoft.com/en-us/library/jj635153.aspx and specifically the "DeleteDeploymentDirectoryAfterTestRunIsComplete" setting
I recently run into problems when running all my unit tests at once.
I can debug them and run my tests seperate without problems, but when running them all together, the test-run keeps hanging half way through.
This happens:
"Run all tests in Solution"
The first tests parses without problem (slower then usual though)
At some point it gets stuck. Nothing fails, no exceptions, VS just stops running the pending tests.
When stopping the test-run it gets stuck again, and I need to restart VS to abort the test-run.
Normally I would expect a bug in my code, but I haven't made any changes to the code beeing testet since last succesful test-run. The only thing I did was run Performance Wizard - Cuncurrency profiling.
It always stops the same place, when removing some tests from the run it stops a new place (still without actually entering any leftover tests).
I have no clue what is causing this. But seems like I'm having problem with a VS setting rather then a code Error.
Any suggestions? Do Performance Wizard change any settings that might have influenced the way test should be run?
System details:
Windows 7 Ultimate 64-bit,
Visual Studio 10 Premium
This sounds like a concurrency issue. It seems that one test changes the testenvironment in such a way that another test runs into a deadlock. When you remove some tests, the test run order is changed and some other tests get stuck.
So I would look for a concurrency issue regarding your test environment/externall dependencies.
I can't really explain why this works, but it solved the problem!
I reversed the '.csproj' file to an earlier version, in one of the projects that had been in 'contact' with the Performance Wizard, and now my tests works.
ALSO Be aware of that Performance Wizard can change the solution configurations from 'DEBUG' to 'RELEASE' mode in some cases. This was not the case for me, but have been a pain for some of my colleagues.
I have a problem which has received plenty of attention which, despite much googling, I have been unable to resolve. I have a Test Project attached to my Visual Studio 2010 MVC 2 Application. When I attempt to run my tests, I get:
"no tests were run because no tests are loaded or the selected tests are disabled."
Following this, I followed the instructions in these posts, to no avail:
MSTest: No tests are run because no tests are loaded or the selected tests are disabled = my GUIDs are right, and the assembly IS being built - I can see the file in explorer.
MSTest Not Finding New Tests = reopening the solution & rebuilding didn't result in any change
http://richallen.blogspot.com/2008/05/ms-test-re-enabling-ignored-tests.html = the tests do not even appear in the test list browser under "loaded tests"
Furthermore, the output console reports:
"Could not load file or assembly 'file://\shared\shared\IT\Development\TPS\TPS.Tests\bin\Debug\TPS.Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)"
I have confirmed the build settings on the Test Project are the same as those for the main project (Any CPU targeted).
Therefore, is it a problem accessing the resource over network share? Otherwise, does anyone have a suggestion?
If you want to continue using a network share to host assemblies in .NET 4, you can change a Visual Studio configuration option to grant those assemblies full trust. You need to edit C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config and add the following line:
<loadFromRemoteSources enabled="true"/>
To the configuration/runtime element. This is described in (slightly) more detail at http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx. I would not recommend making this change without understanding the security implications of doing so, some of which are outlined in that MSDN article.
In general, though, I agree with the previous answer. Hosting Visual Studio projects on a network share is going to create a large number of problems for very little benefit.
Having your source code on a share is plain wrong (period) and will lead to all sorts of 'gremlins'.
Do yourself a favour, use Source Code Control and have a local copy of the source code. You will waste a lot less time, and as a bonus you will be able to track who changed what.
If you go with TFS, the Visual Studio TFS Branching Guide 2010 is a valuable resource.
If you use SubVersion, then the Red Bean Book is excellent.
I was running all local but still had the problem. I found that what caused it was removing an xml tag during manual editing.
add:
CodedUITest() inside of tag brackets
on the line immediately above your class where all your test methods are.
add:
TestMethod() inside of tag brackets
on the line immediately above your test methods you want to run.
build project and run.
I tried the following steps while encountering this problem and luckily the issue got resolved...
Close the solution and open the empty VS editor and Check out the testrunconfig file
Open the solution and under CodeCOverage column, uncheck and check the dll's available( these dll's would be having a warning symbol)
Rebuild the solution and now run the test cases.
Hope this resolves the issue... :)
I struggled with this for days, and didn't find the answer (for my situation) anywhere, so though I'd jot down my experience...
So I had the same problem, doing what I thought was local testing on a test project created locally.. (I'm a novice...) but returning the same error mentioned above : /
Anyway it seems that VS2010 had by default placed my project dir within the library folder, which was classified as network, subsequently all files within were 'unavailable offline'.
By moving my project dir to c:// my project files became index-able. (much to my relief!)
I am using Visual Studio Ultimate and I cannot get code coverage data. All of my unit tests pass, and I edited the Local.testsettings file to enable code coverage and configured it to reference the dll of my project. Also the active test setting is set to Local.testsettings and not TracAndTestImpact.testsettings.
I had the same problem. I configured my .testsettings to include code coverage as detailed here: http://msdn.microsoft.com/en-us/library/dd504821(VS.100).aspx
What I was doing wrong is that I was running the test by pressing F5 in Visual Studio.
What I needed to do was double-click the ".vsmdi" file, which will open the "Test List Editor". Then I clicked the "Run Tests in Current Context" - (Ctrl+R, T) in the Test Code command bar. Code Coverage worked after that.
Hope this helps.
Don't know if you still have this problem, but I had a similar issue and I've managed to fix it. I removed the testrunconfig file from my solution folder. Then added it back in and it came up with the settings dialog box, where I enabled the code coverage. Then I double clicked on code coverage and it came up with a list of dlls and I selected the ones that I needed. It saved the settings correctly and now when I run my tests, I can see the results in code coverage.
Hope this helps someone.
I had trouble getting this to work until I found out that the test project must use the 4.0 .NET Framework (or later).
I tried running the test from the test list rather than the testresults window and that fixed it for me.
I tried all the suggestions above, and in fact nothing worked until ... I restarted Visual Studio.
Visual Studio seems to be modifying a list of .vsmdi files in my .sln every time sometimes when I run a unit test. This is annoying because my source control client thinks the .sln file needs to be checked in even though I don't want to check it in. Is there any way to keep Visual Studio from munging the .sln file after a test run?
Edit: Found a Microsoft Connect issue discussing this, which sucks because things just sort of disappear from there after a little while and its a terrible bug tracker
I don't believe a solution exists. A good Connect case, that does a better job of documenting the issue and a repro case, is this one. At the very bottom of the page a commenter proposes a workaround, which I've reproduced here. I haven't actually tested this workaround for myself yet, I guess I've gotten numb to discarding the changes caused by this bug :(
From the connect case:
I have been able to repro this problem
by having developer A run tests with
the vsdmi file while developer B check
it out and adds unit tests to the
vsdmi. This typically will cause a new
one to be generated.
The workaround that has worked for me
is to create vsdmi files per dev for
unit testing activities that are not
checked in to SCC and create special
vsdmis for build testing and automated
regression.
Yuck, but it works.
Edit: Oops, was confused about the "list of vsmdi files" thing. Suggestion wouldn't have worked.
That is a question for the ages...I always check if the solution has been checked out for whatever reason before I commit changes.