I have a unit two unit test files in Visual Studio 2012. When I build the project and go to the Test Explorer, I only have the unit tests from the first test file. Both test files classes have the same namespaces included and the classes are decorated with the [TestClass] attribute, the methods with [TestMethod] attribute.
What do I need to do to include the second text class?
Did you make it public?
Did you clean and build the solution?
Try Exit and re enter the VS2012.
It happend to me too and the above actions solved it
Related
I have a local nuget package which contains a single test. The test is decorated with [TestClass] and it's test method is [TestMethod].
The reason this is a nuget package is because this test will be brought in to any test projects in order to test that a t4 transform has occurred in the referenced assemblies. The t4 template generates classes dynamically and I want the test to run to verify the t4 template has been executed (using reflection to make sure the generated classes have the expected methods)
When I reference the nuget package, the Visual Studio Test Explorer never displays the test. I was under the impression that VS reflected over the types in the assemblies to build it's test list, but that seems to be an incorrect assumption.
Is there a configuration setting or something that I am missing in order to have the test discovered?
Thank you,
Jason
Visual Studio Test Explorer can only run tests from multiple test projects in a solution and from test classes that are part of the production code projects.
There are two workarounds for your scenario:
Run the test from command line.
Instead of placing the generated dll file in the nuget package, placing the test class file in the "content" folder of the nuget package. This will add the test class file to your project when install the nuget package and then Test Explorer will detect the tests after building the solution.
I am having difficulty building an ordered test in Visual Studio 2015 Enterprise (Update 1) and having the unit tests within the ordered test be able to reference my .runsettings.
Specifically, I need to access the TestRunParameters defined in the .runsettings file.
In any of my test methods, if I access the Properties of the TestContext, the properties I defined in the .runsettings are not found.
Surely I'm not the first to do this. Any help would be appreciated.
I think I understand the bug in Visual Studio. Whenever you select a runsettings file in the VS->Test->Test Settings submenu, they do NOT take effect until I at least do a Rebuild of my Test project (or a Clean solution / Build solution). Simply building does NOT make VS apply the proper runsettings file. There were certain situations where it wasn't applying any runsettings file, but since I started doing a Rebuild Project every time I select a different runsettings file, I've never discovered the TestContext not having my Proerties.
I'm building ~600 projects to a flat file structure (this includes a bunch of unit test assemblies). I'm following a naming convention to easily identify unit test assemblies (.utest.dll).
TFS Build is finding the correct unit test projects to build, but it's not copying their respective app.config files to the flat file structure before trying to execute the unit tests.
What would be the easiest way of having every test use their own app.config file?
You can add the following attribute to your test method to have the app.config file deployed.
[DeploymentItem("app.config", "targetFolder")]
Check this MSDN article for the details: https://msdn.microsoft.com/en-us/library/vstudio/ms182475(v=vs.120).aspx
I have DLL plug-in, which I'd like to test and launch on TeamCity: it contains .h and .cpp files
What is the right strategy to test this DLL:
Create a new Test Project in the same solution, configure 'include directory' to see sources and copy DLL project files to Test console project. In this case I have the same solution but in console mode, which I can test in normal way. But if my DLL project will change I need to synchronize source files.
Create export function in my DLL, like 'runTests()' which will produce XML file with results. TeamCity will process this? And how should it run this? And some stuff function appears in release DLL...
To unit test our libraries, we create standalone unit testing console executables. so:
For each library , we create a console executable testing each method in the API.
Each source file is obviously added to a SCM so modifying files will automatically be reflected into the unit testing program;
All this (source updates, compilation, unit testing and doc generation) is added to our CI server (Jenkins) so that all libraries, for all unit testing programs are always recompiled from scratch;
The documentation for the library API is constructed with Doxygen using snippet from this program. This has a nice side-effect: changing the API will break your unit tests. So you have to fix your unit tests so your documentation is always up to date.
Is there a way to set breakpoints and step through them using NUnit with a mixed project of native C++ and managed C++?
I have my SUT (Software Under Test) configured as a static library (native C++)
I have my unit test suite as a separate project configured as a dll that depends on my previously stated library. I also added said library as a reference to my unit test project.
My tests run fine in NUnit, breakpoints just don't work.
Again, is there a way to get the breakpoints to work with NUnit with Native/Managed C++?
The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.
With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:
$(ProjectDir)$(ProjectFileName) to open the VS Project rather than the assembly. If you use this approach, be sure to rename your config file accordingly and put it in the same directory as the VS project file.
$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) to run the assembly directly. Note that this requires hard-coding part of the path, including the configuration.
If you would like to debug your tests, use the Visual Studio Debug | Processes… menu item to attach to NUnit after starting it and set breakpoints in your test code as desired before running the tests.