Как указать параметры тестового метода с помощью TestDriven.NET?

Я пишу модульные тесты с помощью NUnit и плагина TestDriven.NET. Я хотел бы предоставить параметры для тестового метода следующим образом:

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

    ...
}

Как вы можете видеть, эти параметры являются частными данными, поэтому я не хочу их жестко программировать или помещать в файл. На самом деле я не хочу писать им где-либо, я хочу, чтобы каждый раз, когда я запускал тест, мне нужно было спросить.

Когда я пытаюсь запустить этот тест, я получаю следующее сообщение в окне вывода:

TestCase "MyProject.MyTests.TestLogin" не выполнен: аргументы не предоставлены

Итак, мой вопрос: как мне предоставить эти параметры? Я ожидал, что TestDriven.NET отобразит приглашение, чтобы я мог вводить значения, но это не...

Извините, если мой вопрос кажется глупым, ответ, вероятно, очень прост, но я не нашел ничего полезного в Google...

EDIT: Я только нашел способ сделать это, но это грязный трюк...

    [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 }
            };
        }
    }

Меня все еще интересует лучшее решение...

ОТВЕТЫ

Ответ 1

Тесты блоков обычно не должны принимать никаких параметров. Вы создаете необходимые данные в самом тесте.

  • Ожидаемое значение
  • Вы вызываете свой метод, который хотите проверить, передавая необходимые аргументы
  • Вы сравниваете результат с ожидаемым значением и возвращаемым значением из вашего тестируемого метода.

Тесты MS Unit не позволяют передавать параметры на тесты. Вместо этого вам нужно создать тесты Datadriven Unit. Попробуйте ссылку, это может вам помочь.

Как я уже говорил. Я бы не стал передавать аргументы в модульные тесты, являющиеся хорошей практикой.

Обновление: Я был молод:). Рассмотрим Sarfraz вместо ответа на вопрос о том, как передавать параметры на тесты NUnit.

Ответ 2

Используйте атрибут TestCase.

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

Ответ 3

Я думаю, что вы можете решить эту проблему, используя плагин RowTest для NUnit, найденный здесь http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/

Вы можете создавать простые управляемые данными тесты, где тестовые данные предоставляются атрибутами [Row]. Итак, вот пример теста, который запускается снова и снова с различными параметрами:

[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);
 }
}

Ответ 4

Я согласен с другими ответами, что передающие аргументы могут быть не лучшей практикой, но ни один из них не является жестким кодированием учетных данных или адресов серверов, которые могут измениться в какой-то момент.

Вдохновленный предложенным решением, я просто читаю консольный ввод вместо использования ящиков ввода. Аргументы сохраняются в файле. При запуске тестов файл перенаправляется и считывается из некоторой функции инициализации, которая должна быть вызвана до запуска любых тестовых случаев.

nunit tests.dll < test.config

Это позволяет избежать взаимодействия с пользователем и должно выполняться с помощью любой автоматизации script. Недостатком является то, что пароль все равно должен быть где-то сохранен, но по крайней мере его можно сохранить локально на машине тестеров и легко изменить.

Это было для проекта, где были использованы листы excel, содержащие тесты (а не модульные тесты по определению), чтобы позволить другим создавать тестовые примеры для более крупного проекта на стороне сервера без изменения какого-либо кода. Было бы неплохо, если бы все тестовые случаи были вынуждены на одном гигантском листе. Также не было CI, всего несколько тестовых сред на разных серверах.