How do I specify test method parameters with TestDriven.NET?

Question

I'm writing unit tests with NUnit and the TestDriven.NET plugin. I'd like to provide parameters to a test method like this :

[TestFixture]
public class MyTests
{
    [Test]
    public void TestLogin(string userName, string password)
    {
        // ...
    }

    ...
}

As you can see, these parameters are private data, so I don't want to hard-code them or put them in a file. Actually I don't want to write them anywhere, I want to be prompted each time I run the test.

When I try to run this test, I get the following message in the output window :

TestCase 'MyProject.MyTests.TestLogin' not executed: No arguments were provided

So my question is, how do I provide these parameters ? I expected TestDriven.NET to display a prompt so that I can enter the values, but it didn't...

Sorry if my question seems stupid, the answer is probably very simple, but I couldn't find anything useful on Google...

---

EDIT: I just found a way to do it, but it's a dirty trick...

    [Test, TestCaseSource("PromptCredentials")]
    public void TestLogin(string userName, string password)
    {
        // ...
    }

    static object[] PromptCredentials
    {
        get
        {
            string userName = Interaction.InputBox("Enter user name", "Test parameters", "", -1, -1);
            string password = Interaction.InputBox("Enter password", "Test parameters", "", -1, -1);
            return new object[]
            {
                new object[] { userName, password }
            };
        }
    }

I'm still interested in a better solution...

Answer 1

Unit Tests should normally not take any parameters. You create the necessary data within the test itself.

• The expected value
• You call your method you want to test passing the necessary arguments
• You compare the result with the expected value and the returned value from your tested method

MS Unit tests don't allow the passing of parameters to tests. Instead you need to create Datadriven Unit tests. Try the link, it may help you.

As I mentioned. I wouldn't declare passing arguments to unit tests itself good practice.

---

Update: I was young :). Consider Sarfraz's answer instead on how to pass parameters to NUnit tests.

Answer 2

Use the TestCase attribute.

[TestCase("User1", "")]
[TestCase("", "Pass123")]
[TestCase("xxxxxx", "xxxxxx")]
public void TestLogin(string userName, string password)
{
    // ...
}

Answer 3

I think you can solve this problem by using the RowTest plugin for NUnit found here http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

You can create simple Data-Driven Tests where the test data is provided by [Row] attributes. So here is an example of a test that is run over and over again with different parameters:

[TestFixture]
public class RowTestSample
{
 [RowTest]
 [Row( 1000, 10, 100.0000)]
 [Row(-1000, 10, -100.0000)]
 [Row( 1000, 7, 142.85715)]
 [Row( 1000, 0.00001, 100000000)]
 [Row(4195835, 3145729, 1.3338196)]
 public void DivisionTest(double numerator, double denominator, double result)
 {
    Assert.AreEqual(result, numerator / denominator, 0.00001);
 }
} 

Answer 4

I agree with the other answers that passing arguments may not be best practise, but neither is hard coding credentials or server addresses that may change at some point.

Inspired by the suggested solution in question, I simply read console input instead of using input boxes. The arguments are saved in a file. When starting a the tests, the file is redirected and to be read from some initialization function that should be called before any test cases run.

nunit tests.dll < test.config

This avoids user interaction and should be runnable by any automation script. Downside is that the password still has to be saved somewhere, but at least it can be saved local on the testers machine and is easy to change.

This was for a project, where excel sheets containing the tests (not unit tests by definition) were used to let others create test cases for a bigger server side project without changing any code. It would have been bad if all test cases had to be forced in a single giant excel sheet. Also there was no CI, just many testing environments on different servers.