I can add an attribute on a test to ignore it:
[Test]
[Ignore("Foo Bar")]
Is there a way to ignore all tests in a file (at the TestFixture level)?
[TestFixture, Ignore("reason")]
public class YourTestFixture { }
Or if you prefer to break your attributes out to one per line:
[TestFixture]
[Ignore("reason")]
public class YourTestFixture { }
As suggested, the [Explicit] attribute works well. You can also simply place the [Ignore()] attribute under the [TestFixture] attribute, as shown in the documentation:
http://www.nunit.org/index.php?p=ignore&r=2.5
Use [Ignore()] if you want the test to be flagged as ignored (and therefore you get the yellow bar if all other tests pass). Use [Explicit] if you want the test to be completely discounted (and therefore you get the green bar if all other tests pass).
You can make the whole TestFixture "on-demand" by using the [Explicit] attribute. Then it's there when you want it, but only when you explicitly click on it.
Before NUnit 2.5, removing the [TestFixture] attribute from the class seems like it would work.
This is not the case for NUnit 2.5 and later in which the [TestFixture] attribute is optional for non-parameterized non-generic fixtures. See here for more.
Simply don't apply the TextFixture attribute on the class.
Related
I'd like to limit the default number of iterations for Property Based Tests in Kotest, preferably in the code (instead of using the also existing system property kotest.proptest.default.iteration.count inside my gradle/maven project).
The Global Configuration | Kotest Property Testing page states that I can achieve this by setting PropertyTesting.defaultIterationCount to some value. What I don't get is where to place this assignment. The documentation for Project Wide Configuration in the Framework says I have to override AbstractProjectConfig, which sadly does not include any properties regarding PBT.
The following code works by invoking the assignemnt as a side effect:
import io.kotest.core.config.AbstractProjectConfig
import io.kotest.property.PropertyTesting
class TestConfig : AbstractProjectConfig() {
init {
PropertyTesting.defaultIterationCount = 123
}
}
is there a better way configuring PBT?
The global configuration for Property Testing in Kotest is not tied to Kotest framework itself, because you can use the prop testing modules from JUnit or anything.
So the way to make this work is to set PropertyTesting.defaultIterationCount in some kind of "before project" listener. Now if you're using Kotest framework, it's easy and you're almost there. Just put the assignment inside a beforeProject listener, and it'll be guaranteed to run before any tests.
class TestConfig : AbstractProjectConfig() {
override suspend fun beforeProject() {
PropertyTesting.defaultIterationCount = 123
}
}
In my existing [OneTimeSetup] method, I want to check some preconditions before running any test. But I can't do so as the object which I'll be needing to check preconditions is initialized in Base class [Setup] method. I can't initialize this earlier due to some project limitations.
So, Is there any way where I can execute some code after Base [Setup] method (to check some preconditions) and before any suite execution? I want to execute this once per suite.
[SetUpFixture]
Class GlobalSetup
{
[OneTimeSetUp]
public void OneTimeSetUp(){
setup();
CheckIfDataIsPresent(); // I can't do this here as this code needs Obj O to be initialized. which will be initialized in Base class's [Setup] methed
}
}
Public class Base
{
[Setup]
public void setUp()
{
//some code where we initialize obj O;
}
}
[TestFixture]
public class Test : Base
{
// tests to be executed
}
You already did a nice job of explaining why what you want to do won't work, so I don't have to. :-)
The problem is that each your tests needs a fresh instance of that object, so you properly create it in a [SetUp] method. You would like to ensure that it's possible to create such an object once before you run any tests.
I can only give you a non-specific answer, since you haven't given a lot of info in your example code. If you update your question, I may be able to update my answer. Here goes...
Both your tests and the check you want to perform require an instance of object o. So one approach would be to initialize o one more time in the OneTimeSetup, perform the check and then throw it away. Since you are initializing o in every test, I assume it's not expensive to do so. Say you have 100 tests. You are setting up o 100 times. So make it 101 and be done!
Alternatively, determine what is required for o to be initialized successfully and check that. For example, if it needs a file to be present, check that the file is present. If the file has to have 100 records in some format, check that it's so. Perhaps you might give us more detail about what those prerequisites are.
Finally, you might reconsider whether you really need a new instance per test. Since you suggest you would be willing to make a check once per fixture (I assume that's what you mean by suite) then perhaps you really only need one instance per fixture rather than a new one for each test.
We are creating Nunit tests which have corresponding Jira stories. We have been putting the ticket reference in the test name, but is there a convention or Nunit attribute that we should consider using instead which would be a useful or organised place for putting this reference instead?
Many folks use the [Description] attribute for this purpose.
Another option is to use [TestOf]. While it's aimed at specifying the class or method that you are testing, you can use it for any other string description if you don't make use of it for that purpose.
Finally, you can trivially create your own property attribute. For example:
c#
public class JiraTicketAttribute : PropertyAttribute
{
public JiraTicketAttribute(string ticket) : base(ticket) { }
}
The test on which it is used will end up with a property named "JiraTicket" with the value you specify as an argument.
Using Eclipse (Helios), I could create a JUnit test file ClassATest.java of the source file ClassA.java by using New -> JUnit Test Case -> Class under test..., then choose all the methods of ClassA to be tested.
If later we add some more methods to ClassA, how do we easily reflect this addition in ClassATest ? (No copy/paste plz).
One solution is to use MoreUnit
With MoreUnit installed to Eclipse, one can right click onto the newly added method (and not yet unit tested), and choose "Generate Test"
Of course, if one always follows the writing-test-before-writing-method style, then this solution is not needed. However in reality sometimes you don't have a clear idea of what you would want to do, in that case you would have to code up some method, play with it, then rethink and code again until you are satisfied with the code and want to make it stable by adding unit test.
You should look into creating a JUnit test suite which will execute all tests within the classes you specify. Thus, adding new test cases is as simple as creating a new class and adding it to the #Suite.SuiteClasses list (as seen below).
Here's an example.
Example JUnit Test Suite Class:
#RunWith(Suite.class)
#Suite.SuiteClasses({
TestClassFoo.class
})
public class ExampleTestSuite {}
Example Test Case class:
public class TestClassFoo {
#Test
public void testFirstTestCase() {
// code up test case
}
}
Is there some global state somewhere that I can access the currently-running test name?
I have tests which output files into a directory and read them back in. I'd like each test to create a directory to play in and then clean up after itself, and I don't want to push that name in (I'd have to make it unique, and then make sure each test keeps it unique; ew). I could use a GUID, but I'd like helper methods to be able to assume "this is the place where test files should be stored" without having to push that GUID around to them. Again, this augers for a global state somewhere.
Basically, I want a call like TestRunner.Current.CurrentTest.Name. Does such a thing exist?
(Assuming c#)
NUnit.Framework.TestContext.CurrentContext.Test.Name
or
NUnit.Framework.TestContext.CurrentContext.Test.FullName
or if you are really lazy and aren't driving your tests with TestCaseSource (thanks #aolszowka):
this.GetType().ToString()
I haven't upgraded to 2.5.7 yet myself, but it includes a TestContext class that seems to provide just what you're looking for: http://www.nunit.org/index.php?p=releaseNotes&r=2.5.7
Assuming one method per Test, in your NUnit code, you can use reflection to get the method name from the stacktrace.
If you write a helper method in your NUnit code called by other methods to do this file logging, you can use this syntax to check for the previous method:
string MethodName = new StackFrame(1).GetMethod().Name;
See the answers to question 44153, "Can you use reflection to find the name of the currently executing method?" for more details.
If we are using TestCaseSource tag then above solutions might not give correct answer
Try using TestContext.CurrentContext.Test.MethodName
Follow the below example
namespace NunitTests
{
public class Class1
{
static List<TestData> Data = new List<TestData>()
{
new TestData()
{
...
}
};
[Test]
[TestCaseSource(nameof(TenMBInstance))]
public void TestCase(TestData value)
{
TestContext.CurrentContext.Test.Name; //TestCase(NunitTests..TestData)
TestContext.CurrentContext.Test.MethodName; //TestCase
}
}
}