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?
Related
This question is very similar to other questions that also in some cases literally have the text "tests not running in Test Explorer" in the title. But, my context is a bit different. In those questions, there was a fair bit of investigation into what might be wrong with the tests. I am fairly confident nothing is wrong with the tests in this case.
I am one of hundreds of developers working on a project, and this project has a large bank of automated tests (though perhaps not as large as it ought to be :-P). Everybody is frequently running tests, and triggers fire when pull requests are made and merged to automatically run them then too. Tests were working fine for me as well. But, I have just been given a new laptop with better hardware specs, and I am trying to get it set up. On the new laptop, the project builds just fine (and noticeably faster :-) ), but the automated tests just don't run. I can't figure out why, and I'm looking for suggestions about what to check in this context -- given that there are hundreds of places where the exact same code is working perfectly, I really don't think the tests or test projects themselves are at fault here.
I have observed that the build output, apparently randomly, sometimes does not contain the test adapter files:
Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll
Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll
Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.dll
xunit.runner.visualstudio.testadapter.dll
If these files are missing, then VSTest.Console.exe also cannot run the test. But, usually rebuilding the project results in the files magically appearing, and then VSTest.Console.exe works just fine.
I haven't been able to ascertain a reason why the adapter files are sometimes put into the build output and sometimes not, and in either case, the Test Explorer within Visual Studio always fails to run the tests -- it discovers the tests just fine, puts several thousand items into the forest of trees, but when told to run tests, it just sits there for a minute or two and then returns to idle state with no output at all in the "Tests" output window.
This is a brand new installation of Visual Studio Enterprise 2019 Preview, the exact same version that is on my old laptop, but on my old laptop the tests run fine. What do?? I don't know what to check next. :-(
Well, I am thoroughly confused. I tried installing new features, I tried checking for system updates, I rebooted multiple times, and tests did not work. So, finally, I decided to make a cut-down minimal test project and see if I could observe any differences in Process Monitor between the two computers. I made a project with two tiny tests, one with NUnit and one with xUnit, and ... they worked. So, I opened up the big project again and hit Run Tests, and ... they worked. I am completely stumped, and the only advice I can offer to anyone finding this question with a similar problem is, just keep trying.
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
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Visual Studio keeps building everything
Visual Studio 2008 keeps rebuilding the entire project as if every implementation file was modified. This happens even if no files were modified. Hit build button twice in row, and the entire projects gets rebuild twice. This doesn't happens on another box. The OS is Windows Vista.
This is very annoying. What could cause such a behavior?
It is a C++ project.
Some ideas to try...
As #David Paxson said in the comments, with some languauges (e.g. C#, VB) all the projects will appear to be "built", but the compiler will skip through the ones that don't need to be built much more quickly, even though they are still listed in the output. So it may simply appear to be rebuilding everything. Also, with C#, Visual Studio sometimes runs the project several times in a row, and sometimes it will decide for no obvious reason that it needs to "rebuild" the projects, but this only usually takes a few seconds extra unless you have hundreds of projects.
Restart Visual Studio (or even reboot the PC entirely).
Do a "Rebuild All" of the entire solution to clean out any old cached information and ensure all the output files are up to date.
If you use source control, then even better is to check in all of your changes, then delete your old source code folder (or safer, rename it somewhere out of the way until you know you don't need it) and force-get all the latest source code from source control again. This means you have a totally clean starting point (a clean or rebuild-all doesn't quite clean everything away, unfortunately). I do this every 2-4 weeks to keep everything running smoothly and totally in sync with the Source Control code.
If anything modifies the datestamps of any files in your build, then this could trigger a "need" to rebuild everything. Check that your system clock is set correctly, that there aren't any datestamps of source files set to times "in the future", and there are no applications running that could possibly "touch" any of your source files.
Check this option: Tools->Options > Projects and Solutions > Build and Run : "Only build startup projects and dependencies on Run". If it is unchecked, then VS will try to rebuild all projects every time, rather than only the dependencies of the startup project. If you have a large solution with a bunch of mostly unrelated projects in it, this is a very helpful option to set.
If there are projects that you don't need to build every time, then use the Configuration Manager to disable building of those projects in your current build (or create a "Debug Fast Build" configuration so you can switch quickly between a full rebuild and a partial build). Or move projects that don't need to be built often into a separate "libraries" solution and reference/link the output files (obj or dll) form your application's Solution, so the libraries only need to be rebuilt if you edit their code.
Lastly, make sure you're doing a "Build" and not a "Rebuild" :-)
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!)
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.