I already have several unitary test written with google test within my solution.
I've just install the "GoogleTest Runner" visual studio extension (2013).
I did not found any user's guide.
Could somesone tell me how to use this extension, please?
Thank you.
Yeah, it took me a while to figure out how to use it as well. The extension integrates with the unit testing facilities that are built-in to visual studio, so when it's enabled you should be able to just click TEST->Run->All tests and it will pick up your test cases automatically.
One of the little hidden details is that the project containing the test cases must be named {something}Test, otherwise the plugin won't know where to look for the test cases.
Related
I wonder has anyone come across with this issue where the MSTest Unit Test doesn’t show up in the new Unit Test Explorer.
I’m running Windows 7 (32bit). I downloaded the VS11 Developer Preview from the link below. http://www.microsoft.com/download/en/details.aspx?id=27543
I created a sample C# Console App, and add the Test Library from the MSTest project template. Then I created a sample Unit Test, and rebuild the solution. When I open the Test Explorer (View->OtherWindows->UnitTest Explorer) I do not see any tests loaded.
I only see a message saying…
“No test discovered. Please build your project and ensure the appropriate test framework adapter is installed”.
I assume the MSTest adapter is automatically installed. If not I’m not even sure how to install an adapter.
I could be missing something here but I cannot figure it out. Has anyone experiencing this issue?
Found out that at this only works with Windows8. (At this stage)
More info
http://jerssoft.blogspot.com/2011/09/vs11-unit-test-explorer-acercamientos.html#more
(you need to translate to English)
"Of course, all this work the right way if we have properly configured and in the final version , since according to understand, if you want to try this plugin, you need to be working with Windows 8 :) "
http://geekswithblogs.net/lbugnion/archive/2011/09/24/running-unit-tests-in-visual-studio-2011-and-windows-8.aspx
If you are using VS Ultimate version of VS 11 developer preview, then it support MStest based unittesting for Windows7 style apps/projects if that is what you were trying out. It is possible that you are hitting a bug. Will it possible for you to share your repro steps?
Thanks,
Abhishek Agrawal
Program Manager, Visual Studio,
Microsoft Corp
This wasn't working for me using Visual Studio Express 2012 Web RC, but I got it going eventually.
I added the reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework which I found in C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies
I made sure this was set to Copy Local but probably not required.
Then I tried cleaning and rebuilding but with no effect. I made sure I didn't have any testsettings selected (Test Menu > Test Settings > Untick the testrunconfig if selected), then changed my Test > Test Settings > Default Processor Architecture to x64 (my machine is x64).
Then I cleaned and rebuilt the solution and my Test Explorer was populated when I click Run All.
Here's the scenario:
'User A' has created unit tests through Visual Studio 2010. The test project and unit test source code have been checked into version control. 'User B' gets the test project and unit test source code from version control. 'User B' then opens the test project and receives a message saying "Error loading blah.blah.blah.vsmdi: Input file not found: blah.blah.blah.vsmdi." However, 'User B' can still run the unit tests successfully.
Now, regardless of whether 'User A' should have checked in the .vsmdi file, there don't appear to be any negative effects, other than the error message.
Is there any harm in not having the .vsmdi file? Or, conversely, what is the benefit of having the .vsmdi file?
The following link gives a bit of good information *.vsmdi files
http://notgartner.wordpress.com/2011/02/10/what-is-a-vsmdi-file/
In brief, content of the link helpful here is:
Originally the use of the *.vsmdi file was a requirement to get MSTest integration with MSBuild working on a TFS build server, however this requirement has since been removed once again removing the utility of the file.
Assuming that you are just using the Test View to run your tests these files are perfectly safe to delete. If you want to try and tackle the problem, there is an imperfect solution. Simply remove all the files from your disk and in version control (assuming you are using TFS here, or any version control system that is integrated with Visual Studio), then instruct the version control system to perform an exclusive check-out.
Well, from what I have gathered, there is no harm in not having the .vsmdi file, when using VS 2010.
Using VSMDI files in VSTS 2005 have known to have many issues regarding maintainability.
Though it may have potential in the future releases of VS, currently it seems better to stay away from it.
Check out the below MSDN blog that details the workaround. Please note this applies only to VS2005. VSTS 2008 now uses testcontainers instead.
How to run tests in a build without test metadata files and test lists (.vsmdi files)
I use NUnit for Mono/C# on my Mac, but I need to use Microsoft.VisualStudio.TestTools.UnitTesting for unit testing.
How is Microsoft TestTools' UnitTesting different from NUnit? Can I just change the namespace and recompile to get the same result, or do I have to rewrite the test?
Can I copy some of the assemblies to my Mac to run tests for Microsoft.VisualStudio.TestTools.UnitTesting? If so, what files should be copied?
See Migrating from NUnit to MSTest.
As to why you might try convincing your team to migrate the other way, see NUnit vs. MsTest: NUnit wins for Unit Testing.
Ask yourself - why do you need the Ms tools if you already have a working set with NUnit.
Personally I've worked with both and unless working in legacy where the MS tool was in great use, I'd choose NUnit for this toolset due to the larger community support I get in cases of problems.
MSTest can be used without installing Visual Studio. You will need to install Visual Studio Test Agent, which is a free download from Microsoft: http://www.microsoft.com/download/en/details.aspx?id=1334.
I think this approach is better from a licensing perspective than manually copying MSTest.exe and its dependencies onto the build server.
My biggest problem with MSTest is that it requires the install of Visual Studio, even if you are trying to run a lean build server.
NUnit can install and run anywhere.
I want to be notified when a build has been completed\failed in visual studio and I DO NOT want to use pre\post build steps, I want an external process or VS plugin that will count the number of builds.
So is there anyway to achieve this using something like WMI or other such technology?
I'm not interested in third party libaries, I want to write a plugin for visual studio.
There isn't. You can either use the pre/post build steps, or make an add-in. For the latter look for EnvDTE.BuildEvents. Let me know if you need a sample.
Any particular reasons you don't want to use the pre/post build steps, you can pretty much do anything with them, i.e. send mail, increment the file version information in AssemblyInfo etc.
The TFS PowerToys for 2008 or 2010 includes a build notification tool.
I am using this free VS plugin for Build status.
You can find it here.
I realise that there are many older questions addressing the general question of NUnit v MSTest for versions of Visual Studio up to 2008 (such as this one).
Microsoft have a history of getting things right in their 3rd version. For MSTest, that is VS2010.
Have they done so with MSTest? Would you use it in a new project in preference to NUnit?
My specific concerns:
speed
running tests within CruiseControl.NET (either commandline or MSBuild task)
code coverage reports from CC.NET
can you run MSTest tests in debug mode
(We use ReSharper, so test-runners are not an issue for us. We have used NUnit for the last few years. We do not have TFS.)
List item speed is same, but MsTest may be a bit slower because it creates folder for test run every time
MSBuid and CC.Net is big pain. You can't run MSTest on computer without VS on it (not 100 sure about 2010, but with 2008 it is so)
not sure, sorry
yes you can, from visual studio
My recommendation is following: if NUnit satisfies you - use it, forget about MSTest
To correct some old information on the thread;
It IS possible to run 64 bit tests in 2010
From VS2008 forward it is not neccesary to have MSTEST create directories anc opy the binaries in, just disable deployment, in 2010 thats the default but you have to set it in 2008
2010 MSTEST is faster but as its a generalised test framework that also runs load/web/UI tests there are compromises in the design that will lead to it being slower. Jamie Cansdale appears to have managed to get perf increases with the lastest releases of TestDriven.net's support for MSTEST
I've mainly used NUnit, some xUnit and some MSTest. They seem functionality equivalent, but I don't like the MSTest test runner. It runs in visual studio so it either crowds the screen or is on another monitor getting in the way everytime I tab to visual studio. (I run NUnit on another monitor, but it doesn't cover everything on that monitor everytime I focus visual studio). It takes too many clicks to find out what test failed and why.
NUnit can run in the background until a test fails, at which point it shows you information about the breaking test. This seems like the ideal for keeping red/green/refactor going smoothly.
Nope. Same issues regarding appdomains and assembly resolving still exist. I would avoid unless you want the new goodness for other functional testing or integration with Team System.
I don't know much about CruseControl.net, but you can debug tests. We currently don't use TFS either, and the MSTest is working for us.
If you think you'll ever run your tests in 64 bit mode, use NUnit. MsTest is only x86.
One major difference between the two is that MSTest makes a copy of the current DLLs every time it runs a test. If you're doing TDD and running your tests frequently, this can eat up a lot of hard drive space.
If you're using MSTest, you can change this setting in Tools > Options > Test Tools > Test Execution. "Limit number of old Test Results to" is set to 25 by default in Visual Studio 2010. I usually change it to 1.
MSUnit runs your test cases under conditions that are different from the actual execution environment. Specifically, the deployed files differ from those that are deployed when you run your actual project. Nethertheless, there is the [DeploymentItem]-Attribute to specify which files shall be deployed by MSUnit. So if your application depends on any external
files, such as
database files
database configuration file
application configuration file
...
then MSUnit is not the right choice, because the MSUnit tests never cover what your file system is going to look like in execution environment. The Visual Studio Project File settings for deploying files (Copy always, Content, etc.) are ignored by the MSUnit runner. So those settings cannot be tested.