I am using MStest to run a single test case but could not find a correct command
I tried:
1)mstest.exe /testcontainer:testproject.dll /test:MethodTest1
This run all the test case starting from name MethodTest1. I have other test name Like MethodTest100, MethodTest101
2)mstest.exe /testcontainer:testproject.dll /test:MethodTest1 /unique
This needs to pass Test Namespace name and Test Class name.
It works when i execute following but i have only access to Test Method not to class or namepsace
mstest.exe /testcontainer:testproject.dll /test:TestNamespace.TestClass MethodTest1 /unique
I would appreciate if somebody could help me in exact command to run a single test case without using Class Name or Name pace in which TestMethod Lies.
Thanks
For running multiple tests under a given class or namespace, you can use a wild card *.
So, running:
mstest.exe /testcontainer:testproject.dll /test:TestNamespace.TestClass.*
will work
A test case name only needs to be unique within the context of a test class, and a test class name only needs to be unique in the context of a test namespace. Therefore, when you want to run a single test (by name) you always have to also supply the names of the containing namespace and class. Otherwise, MSTest is not able to uniquely identify the test you want to have run.
Related
Using googletest you can name your parameterized tests based on the parameters using the last argument in INSTANTIATE_TEST_SUITE_P.
Now I am using BOOST_DATA_TEST_CASE, and the tests are currently named _0, ..., _N which makes them hard to distinguish. Is there any way that the boost tests can be named in a similar way to googletests parameterized tests?
I have to run tests in a specific order using build.gradle file.
I have the build.gradle file looks like the following:
test {
include 'com.my-project.MyTestClass'
include 'com.my-project.MyTestClass1'
}
but when I running test task I have the following message:
Tests event were not received
How can I fix this problem?
That message just means that no tests were actually run. There could be a number of reasons for that, but the most likely given your example is that the include method takes an Ant style file pattern, but you have given it (fully qualified) class names. Also, 'my-project' is not a valid package name, but I assume this is just a error in your example here.
But more importantly, if your intent is to run tests in a specific order, you will not achieve that with a single test task. The specified includes just tell Gradle what tests are part of the suite, but doesn't affect the order.
I don't know what test framework you are using, but I also don't think it is possible with JUnit 4 and 5. The only way I can think of is to create multiple Test tasks in Gradle, where each task represent a single unit test (or group of tests that can be run in any order), and where you order each task through dependsOn. So something like this:
task myTest1(type: Test) {
include 'example/MyTestClass1.class'
}
task myTest2(type: Test) {
dependsOn myTest1
include 'example/MyTestClass2.class'
}
test {
exclude 'example/**'
dependsOn myTest2
}
I'm curious as to why the fixture setup must be static? It seems more intuitive to me to have instance variables per fixture that share the lifetime of the fixture.
Yes, these can be initialized in the constructor, but then I assume they are out of reach of the control of the test runner.
What design requirements or philosophies determined that the setup method should be static?
The method with the ClassInitialize attribute runs once for all the tests in the class. An instance of the class is created each time a test is run, so it has to be static in order to only run once.
If you want to initialize for every test, then you can use the TestInitialize attribute, which will run whenever a new instance of the class is created (before running a test).
If you need more info, you can check out:
That Pesky MSTest Execution Ordering
I am trying to implement AssemblyInitialize/AssemblyCleanup attributes in my Microsoft Visual Studio 2010 for the exact purpose as stated here. That link even describes the process which I need to follow to implement the code.
A quick summary of that purpose is to create an initial block of code which will run right before any test no matter which of the codedUITests I run in the solution and then a block of code which will run after the last codedUITest is completed. Example: I need to open up a specific application, then run a series of codedUITests which all start at that application and which are executed in any order, then close the application after everything is finished; this is more efficient than opening/closing the application for each codedUITest.
What I don't understand is where I need to place the code laid out at the bottom of that page (also shown below). I stuck all that code right under my 'public partial class UIMap' and the code runs except it runs the 'OpenApplication' and 'CloseApplication' commands before/after each CodedUITest instead of sandwiching the entire group of CodedUITests.
How do I implement the code correctly?
Update:
I discovered AssemblyI/C last night and I spent 3 hours trying to
figure out where to put the code so it works. If I put the
AssemblyInitialize at the beginning of a specific test method then:
1) It still wouldn't run - it was giving me some error saying that
UIMap.OpenWindow() and UIMap.CloseWindow() methods need to be static
and I couldn't figure out how to make them static.
2) Wouldn't the specific [TestMethod] which has the AssemblyI/C on it
need to be in the test set? In my situation I have a dozen
CodedUITests which need to run either individually or in a larger
group and I need to get the AssemblyI/C to Open/Close the window I am
testing.
You've added the methods to the wrong class. By putting then into the UIMap partial class, you are telling the runtime to run those methods every time you create a new UIMap instance, which it sounds like you're doing every test.
The point of the ClassInitialize/ClassCleanup methods is to add them to the class with your test methods in it. You should have at least one class decorated with the TestClass attribute, which has at least one method decorated with a TestMethod attribute. This is the class that needs the ClassInitialize and ClassCleanup attributes applied to it. Those methods will run one time for each separate TestClass you have in your project.
You could also use the AssemblyInitialize and AssemblyCleanup attributes instead. There can only be one of these methods in any given assembly, and they will run first and last, respectively, before and after any test methods in any classes.
UPDATE:
AssemblyInitialize/Cleanup need to be in a class that has the TestClass attribute, but it doesn't matter which one. The single method with each attribute will get run before or after any tests in the assembly run. It can't be a test method, though; it has to be a static method and will not count as a "test".
I am having an interesting situation. In my test assembly, I have folders having specific test classes, i.e., TestFixture's. Consider, for e.g., the following hierarchy in VS:
Sol
TestProject
TestFolder1
TestClass1
TestClass2
TestFolder2
TestClass3
Now, when I run the following at command line:
nunit-console.exe /run:Sol.TestProject.TestFolder1.TestClass2 TestProject.dll
Things are running fine and all the tests are passing. But, if I run as below:
nunit-console.exe /run:Sol.TestProject.TestFolder1 TestProject.dll
In this case, some of the tests in TestClass2 are failing.
I have tried dumping the state of some of the relevant objects involved in the test, and the state seemed fine at the beginning of the test code in both cases. Also, TestClass1/2/3 do not have a superclass doing something - so that is ruled out as well. Any ideas what else can be happening here?
I am using VS2010/.NET4.0 (4.0.30319.1)/nUnit 2.5.9.
Finally figured this out. I was using a singleton class for storing certain options. Looks like the singleton class instance is retained between runs of different TestFixtures (i.e., test classes), when they are run together, e.g., for a folder or for a project. I did not dump the state of this object initially, because I thought that the singleton class will be having new instance for each of the TestFixtures. Interesting finding, hope this helps someone.