C# – Is it possible to parameterize a nunit test

cnunit

I would like to write a callable function that accepts two objects, and compares 30+ properties of those objects with asserts. The issue is this needs to be done for about 20 existing unit tests and most future tests, and writing out the 30+ asserts each time is both time and space consuming.

I currently have a non unit test function that compares the objects, and returns a string with "pass" or a failure message, and use an assert to validate that in each unit test. However, its quite messy and I feel like I'm going against proper unit testing methods.

Is there a way to make a function that is callable from inside unit tests that uses asserts to check conditions?

Best Answer

If you are using NUnit 2.5.5 or above, this is possible using the TestCase attribute.

Normal unit tests would be decorated with [Test], but we can replace that as follows:

[TestCase("0", 1)]
[TestCase("1", 1)]
[TestCase("2", 1)]
public void UnitTestName(string input, int expected)
{
    //Arrange

    //Act

    //Assert
}

That type of thing will be the way to do it - obviously take different params.

Look at this for help: http://nunit.org/?p=testCase&r=2.5

Related Solutions

C# – How to test database-related code with NUnit

NUnit now has a [Rollback] attribute, but I prefer to do it a different way. I use the TransactionScope class. There are a couple of ways to use it.

[Test]
public void YourTest() 
{
    using (TransactionScope scope = new TransactionScope())
    {
        // your test code here
    }
}

Since you didn't tell the TransactionScope to commit it will rollback automatically. It works even if an assertion fails or some other exception is thrown.

The other way is to use the [SetUp] to create the TransactionScope and [TearDown] to call Dispose on it. It cuts out some code duplication, but accomplishes the same thing.

[TestFixture]
public class YourFixture
{
    private TransactionScope scope;

    [SetUp]
    public void SetUp()
    {
        scope = new TransactionScope();
    }

    [TearDown]
    public void TearDown()
    {
        scope.Dispose();
    }


    [Test]
    public void YourTest() 
    {
        // your test code here
    }
}

This is as safe as the using statement in an individual test because NUnit will guarantee that TearDown is called.

Having said all that I do think that tests that hit the database are not really unit tests. I still write them, but I think of them as integration tests. I still see them as providing value. One place I use them often is in testing LINQ to SQL code. I don't use the designer. I hand write the DTO's and attributes. I've been known to get it wrong. The integration tests help catch my mistake.

C# – Unit Testing File I/O

There isn't necessarily one thing to do when testing the file system. In truth, there are several things you might do, depending on the circumstances.

The question you need to ask is: What am I testing?

That the file system works? You probably don't need to test that unless you're using an operating system which you're extremely unfamiliar with. So if you're simply giving a command to save files, for instance, it's a waste of time to write a test to make sure they really save.
That the files get saved to the right place? Well, how do you know what the right place is? Presumably you have code that combines a path with a file name. This is code you can test easily: Your input is two strings, and your output should be a string which is a valid file location constructed using those two strings.
That you get the right set of files from a directory? You'll probably have to write a test for your file-getter class that really tests the file system. But you should use a test directory with files in it that won't change. You should also put this test in an integration test project, because this is not a true unit test, because it depends on the file system.
But, I need to do something with the files I get. For that test, you should use a fake for your file-getter class. Your fake should return a hard-coded list of files. If you use a real file-getter and a real file-processor, you won't know which one causes a test failure. So your file-processor class, in testing, should make use of a fake file-getter class. Your file-processor class should take the file-getter interface. In real code, you'll pass in the real file-getter. In test code you'll pass a fake file-getter that returns a known, static list.

The fundamental principles are:

Use a fake file system, hidden behind an interface, when you're not testing the file system itself.
If you need to test real file operations, then
- mark the test as an integration test, not a unit test.
- have a designated test directory, set of files, etc. that will always be there in an unchanged state, so your file-oriented integration tests can pass consistently.

Best Answer

Related Solutions

C# – How to test database-related code with NUnit

C# – Unit Testing File I/O

Related Topic