Let's say I have the following test case that has been written using xUnit:
public static IEnumerable<object[]> testValues = new List<object[]>
{
new object[] {new double?[] {0.0}, 0.0, 0.0},
};
[Theory]
[MemberData(nameof(testValues))]
public void Test1(double?[] values, double expectedQ1, double expectedQ3)
{
// Test code
}
How could I express the same unit test in nUnit instead of xUnit?
Note: The main problem here seems to be the use of MemberData, which for so far, I haven't been able to find an nUnit equivalent. What would be the correct way of expressing such unit test cases in nUnit?
Like this:
public static IEnumerable<object[]> testValues = new List<object[]>
{
new object[] {new double?[] {0.0}, 0.0, 0.0},
};
[TestCaseSource(nameof(testValues))]
public void Test1(double?[] values, double expectedQ1, double expectedQ3)
{
// Test code
}
Note that NUnit has TheoryAttribute but you don't want it here. In NUnit, a Theory is a bit more than just a parameterized test. You should read the docs to understand what it is before deciding if you need it. Of course, you should read up on TestCaseSourceAttribute as well. :-)
Other attributes in NUnit that allow data to be specified for a test case include TestCaseAttribute, ValuesAttribute, ValueSourceAttribute, RandomAttribute and RangeAttribute.
Related
I have a test that takes in test data. When using nunit console app to run the test, is there a way I can specify the data to be used?
Eg:
[Test, TestCaseSource(typeof(TestData))]
public void ATest(string param1, int param2)
public class TestData : IEnumerable
{
public IEnumerator GetEnumerator()
{
yield return new object[] { "blah1 blah1", 1};
yield return new object[] { "blah2 blah2", 2};
}
}
I want to be able to run ATest with test data ["blah2 blah2", 2] only. If I run as follows:
nunit3-console.exe Tests.dll --test=ATest --workers=1 --noresult
it will run twice.
Just run...
nunit3-console.exe Tests.dll --test ATest("blah2 blah2", 2)
or
nunit3-console.exe Tests.dll --where "test~=blah2"
If that string is unique to all your tests.
Note that the first one may require some escaping of the quotes, depending on your operating system.
One way to do this would be through returning a TestCaseData object instead.
Something like this: (untested, so syntax might be a little off!)
[Test, TestCaseSource(typeof(TestData))]
public void ATest(string param1, int param2)
public IEnumerator GetEnumerator()
{
yield return new TestCaseData("blah1 blah1", 1).SetName("FirstTest");
yield return new TestCaseData("blah2 blah2", 2).SetName("SecondTest");
}
To run the first test, you would then use the command line:
nunit3-console.exe Tests.dll --test=YourNameSpace.ATest.FirstTest --workers=1 --noresult
Depending what you're doing, setting the category may be more suitable than the name. The docs page shows what's available: https://github.com/nunit/docs/wiki/TestCaseData
I'm using NUnit 3.0 and TestFixtureSource to run test cases inside a fixture multiple times with different parameters/configurations (I do want to do this at TestFixture level). Simple example:
[TestFixtureSource(typeof (ConfigurationProvider))]
public class Fixture
{
public Fixture(Configuration configuration)
{
_configuration = configuration;
}
private Configuration _configuration;
[Test]
public void Test()
{
//do something with _configuration
Assert.Fail();
}
}
Let's say Test() fails for one of the configurations and succeeds for another. In the run report file and in Visual Studio's Test Explorer the name for both the failed and the succeeded runs will be displayed as just Test(), which doesn't tell me anything about which setup caused issues.
Is there a way to affect the test cases names in this situation (i.e. prefix its name per fixture run/configuration)? As a workaround I'm currently printing to the results output before each test case fires but I would rather avoid doing that.
Since NUnit 3.0 is in beta and this feature is fairly new I wasn't able to find anything in the docs. I found TestCaseData but I don't think it's tailored to be used with fixtures just yet (it's designed for test cases).
I can't find a way to change the testname, but it should not be neccessary, because NUnit3 constructs the testname by including a description of the testfixture.
The example class Fixture from the question can be used unchanged if the Configuration and ConfigurationProvider has an implementation like this:
public class Configuration
{
public string Description { get; }
public Configuration(string description)
{
Description = description;
}
public override string ToString()
{
return Description;
}
}
public class ConfigurationProvider : IEnumerable
{
public IEnumerator GetEnumerator()
{
yield return new Configuration("Foo");
yield return new Configuration("Bar");
yield return new Configuration("Baz");
}
}
The 'trick' is to make sure the constructor-parameter to the fixture is a string or has a ToString-method that gives a sensible description of the fixture.
If you are using NUnit 3 Test Adapter in Visual Studio, then the testfixtures will be displayed as Fixture(Foo), Fixture(Bar) and Fixture(Baz) so you can easily distinguish between their tests. The xml-output from nunit3-console.exe also uses descriptive names, fx: fullname=MyTests.Fixture(Bar).Test
<test-case id="0-1003" name="Test" fullname="MyTests.Fixture(Bar).Test" methodname="Test" classname="MyTests.Fixture" runstate="Runnable" result="Failed" ... >
<failure>
<message><![CDATA[]]></message>
<stack-trace><![CDATA[at MyTests.Fixture.Test() in ... ]]></stack-trace>
</failure>
...
</test-case>
One way to perform such actions is to have find and replace tokens in source code and dynamically build test libraries before execution using command line msbuild. High level steps are
Define test case names as sometest_TOKEN in source then using command line tools like fnr.exe replce _TOKEN with whatever you like. For example sometest_build2145.
Compile the dll with using msbuild for example msbuild /t:REbuild mytestproj.sln. Thereafter execute all test cases in mytestproj.dll.
I have a base object, that contains a Version property, marked as ConcurrencyCheck
public class EntityBase : IEntity, IConcurrencyEnabled
{
public int Id { get; set; }
[ConcurrencyCheck]
[Timestamp]
public byte[] Version { get; set; }
}
This works, however, I want to write a test to ensure it doesn't get broken. Unfortunately, I can't seem to figure out how to write a test that doesn't rely on the physical database!
And the relevant test code that works, but uses the database...
protected override void Arrange()
{
const string asUser = "ConcurrencyTest1"; // used to anchor and lookup this test record in the db
Context1 = new MyDbContext();
Context2 = new MyDbContext();
Repository1 = new Repository<FooBar>(Context1);
Repository2 = new Repository<FooBar>(Context2);
UnitOfWork1 = new UnitOfWork(Context1);
UnitOfWork2 = new UnitOfWork(Context2);
Sut = Repository1.Find(x => x.CreatedBy.Equals(asUser)).FirstOrDefault();
if (Sut == null)
{
Sut = new FooBar
{
Name = "Concurrency Test"
};
Repository1.Insert(Sut);
UnitOfWork1.SaveChanges(asUser);
}
ItemId = Sut.Id;
}
protected override void Act()
{
_action = () =>
{
var item1 = Repository1.FindById(ItemId);
var item2 = Repository2.FindById(ItemId);
item1.Name = string.Format("Changed # {0}", DateTime.Now);
UnitOfWork1.SaveChanges("test1");
item2.Name = string.Format("Conflicting Change # {0}", DateTime.Now);
UnitOfWork2.SaveChanges("test2"); //Should throw DbUpdateConcurrencyException
};
}
[TestMethod]
[ExpectedException(typeof(DbUpdateConcurrencyException))]
public void Assert()
{
_action();
}
How can I remove the DB requirement???
I would recommend extracting your MyDbContext into an interface IMyDbContext, and then creating a TestDbContext class that will also implement SaveChanges the way you have it up there, except with returning a random value (like 1) instead of actually saving to the database.
At that point then all you'd need to do is to test that, in fact, all of the entities got their version number upped.
Or you could also do the examples found here or here, as well.
EDIT: I actually just found a direct example with using TimeStamp for concurrency checks on this blog post.
It's my opinion that you should not try to mock this behaviour to enable "pure" unit testing. For two reasons:
it requires quite a lot of code that mocks database behaviour: materializing objects in a way that they have a version value, caching the original objects (to mock a store), modifying the version value when updating, comparing the version values with the original ones, throwing an exception when a version is different, and maybe more. All this code is potentially subject to bugs and, worse, may differ slightly from what happens in reality.
you'll get trapped in circular reasoning: you write code specifically for unit tests and then... you write unit tests to test this code. Green tests say everything is OK, but essential parts of application code are not covered.
This is only one of the many aspects of linq to entities that are hard (impossible) to mock. I am compiling a list of these differences here.
Using NUnit I wish to run all the tests in a certain project against multiple cultures.
The project deals with parsing data that should be culture neutral, to ensure this I would like to run every test against multiple cultures.
The current solution I have is
public abstract class FooTests {
/* tests go here */
}
[TestFixture, SetCulture ("en-GB")] public class FooTestsEN : FooTests {}
[TestFixture, SetCulture ("pl-PL")] public class FooTestsPL : FooTests {}
Ideally, I shouldn't have to create these classes and instead use something like:
[assembly: SetCulture ("en-GB")]
[assembly: SetCulture ("pl-PL")]
Unfortunatelly this isn't possible now but is planned for future.
You can also do this.
public class AllCultureTests
{
private TestSomething() {...}
[Test]
[SetCulture("pl-PL")]
public void ShouldDoSomethingInPoland()
{
TestSomething();
}
}
Maybe that's something you would prefer?
NUnit's SetCultureAttribute applies one culture to a test, multiple cultures are not (yet) supported.
You can work around this by using the TestCaseAttribute with language codes and setting the culture manually:
[Test]
[TestCase("de-DE")]
[TestCase("en-US")]
[TestCase("da-DK")]
public void YourTest(string cultureName)
{
var culture = CultureInfo.GetCultureInfo(cultureName);
Thread.CurrentThread.CurrentCulture = culture;
Thread.CurrentThread.CurrentUICulture = culture;
var date = new DateTime(2012, 10, 14);
string sut = date.ToString("dd/MM/yyyy");
Assert.That(sut, Is.EqualTo("14/10/2012"));
}
Note that this unit test will fail for de and da - testing for different cultures is really important :)
If you don't mind switching, MbUnit has had this feature for nearly five years now.
You can apply the MultipleCulture attribute at the test, fixture and assembly levels.
I'm using the NUnit 2.5.3 TestCaseSource attribute and creating a factory to generate my tests. Something like this:
[Test, TestCaseSource(typeof(TestCaseFactories), "VariableString")]
public void Does_Pass_Standard_Description_Tests(string text)
{
Item obj = new Item();
obj.Description = text;
}
My source is this:
public static IEnumerable<TestCaseData> VariableString
{
get
{
yield return new TestCaseData(string.Empty).Throws(typeof(PreconditionException))
.SetName("Does_Reject_Empty_Text");
yield return new TestCaseData(null).Throws(typeof(PreconditionException))
.SetName("Does_Reject_Null_Text");
yield return new TestCaseData(" ").Throws(typeof(PreconditionException))
.SetName("Does_Reject_Whitespace_Text");
}
}
What I need to be able to do is to add a maximum length check to the Variable String, but this maximum length is defined in the contracts in the class under test. In our case its a simple public struct:
public struct ItemLengths
{
public const int Description = 255;
}
I can't find any way of passing a value to the test case generator. I've tried static shared values and these are not picked up. I don't want to save stuff to a file, as then I'd need to regenerate this file every time the code changed.
I want to add the following line to my testcase:
yield return new TestCaseData(new string('A', MAX_LENGTH_HERE + 1))
.Throws(typeof(PreconditionException));
Something fairly simple in concept, but something I'm finding impossible to do. Any suggestions?
Change the parameter of your test as class instead of a string. Like so:
public class StringTest {
public string testString;
public int maxLength;
}
Then construct this class to pass as an argument to TestCaseData constructor. That way you can pass the string and any other arguments you like.
Another option is to make the test have 2 arguments of string and int.
Then for the TestCaseData( "mystring", 255). Did you realize they can have multiple arguments?
Wayne
I faced a similar problem like yours and ended up writing a small NUnit addin and a custom attribute that extends the NUnit TestCaseSourceAttribute. In my particular case I wasn't interested in passing parameters to the factory method but you could easily use the same technique to achieve what you want.
It wasn't all that hard and only required me to write something like three small classes. You can read more about my solution at: blackbox testing with nunit using a custom testcasesource.
PS. In order to use this technique you have to use NUnit 2.5 (at least) Good luck.