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
Related
The test explorer (MS-Test) kind of stopped working. It won’t discover any of my tests or sometimes only some of it. When I right click on my test and run it, the output window says “Run test finished: 1 run (time)”, but the test explorer would only display “Last Test Run Failed” (see screenshot), without information about which test or assert failed. I’ve tried restarting the VS, which I thought solved the issue once, but not currently. I’ve also tried build, rebuild, but I just can’t get it working again? Any idea what might help? All of this was working fine until early morning today...
Test Explorer has problems understanding test projects if they are build for x64 or x86, and solution is targeting a different platform.
Also, under Test > Test Settings > Default Test Architecture select appropriate value and then clean and rebuild.
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.
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!)
After years of faithful nUnit use, I'm having a fling with the Visual Studio Unit Testing framework thats built into VS2008.
Apart from the crushing guilt ; ) ... one of the issues is that 'VSTest' creates a file and a folder every time you run tests, and those files ('Visual Studio Test Results File') and folders really build up over time.
Is there an easy way to make it clean up after itself, or a way of preventing it from making those files in the first place?
Unfortunately there is no way to prevent the Unit Test framework in Visual Studio from doing this. However it should not build up uncontrolled. After 25 test runs it will prompt you to delete previous run data before creating a new one thus keeping it at a steady state of 25 directories and associated files.
Are you not seeing that behavior?
is there a way? do I have to wait for building every time I start the test? I want to build from visual studio not from test
thanks
Any time your code changes and you run your test it is going to do a build... so technically you can run your test over and over again and they will only build the first time, but once you run your test why would you run them again without making a code change?
Couple of things that I use that make your test run faster are:
Check the box for "Only build startup projects and dependencies on Run", located Options->Projects and Solution->Build and Run.
Learn the short cut keys
a. "Ctrl+R, T" Runs test in current context, so if your cursor is inside a test method it will only run that test, but when you do it inside of a non test class it will run all of your test.
b. "Crtl+R, Ctrl+T" Debug test same except debug.
c. Others can be found here, those are 2008 if you need to reference others you can find them via google.
Make sure your test are not calling the database or other time intensive resources, use mocking and stubbing.
Run only small sets of test, ie if I am working in a service class I run only the service class test.
Edit: Reading your question again if you want to build and not from a test you can just go to the menu and click Build->Build Solution or press F6. Also it would be helpful if you indicated which version of visual studio you are using because 2010 is different in the sense that you have to click refresh. Either way are you able to clarify?
This is an old question, but I keep seeing people ask it and the issue is still true in VS2017, and it's also true of other test frameworks (Xunit, etc) run from within VS.
I don't know how to make VS stop building all the time. But I do know how to circumvent the compile - run your tests from a console runner, not from within VS. If you're using ReSharper, it has one.
If you aren't using ReSharper, for MSTest, you can start here. https://msdn.microsoft.com/en-us/library/ms182489.aspx
If you aren't using ReSharper, for XUnit, you can start here. https://xunit.github.io/docs/getting-started-desktop.html#add-xunit-runner-ref
Any changes to source code cause compilation, because in order to run tests VS needs up to date DLL with tests.
If you have already compiled project then you can run test multiple times without compilation.
PS: I run MSTest using TestDriven.NET as for me it is faster.