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

Question

Я пишу модульные тесты с помощью NUnit и TestDriven.СЕТЕВОЙ плагин.Я хотел бы предоставить параметры для такого метода тестирования, как этот :

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

    ...
}

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

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

TestCase 'Мой проект.Мои тесты.testLogin' не выполнен:Никаких аргументов представлено не было

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

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

---

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

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

Я все еще заинтересован в лучшем решении...

Answer 1

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

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

Модульные тесты MS не разрешают передачу параметров в тесты.Вместо этого вам нужно создать Модульные тесты с приводом от данных.Попробуйте перейти по ссылке, возможно, это вам поможет.

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

---

Обновить: Я был молод :).Вместо этого рассмотрим ответ Сарфраза о том, как передавать параметры в тесты NUnit.

Answer 2

Используйте Тестовый кейс атрибут.

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

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

Answer 4

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

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

nunit tests.dll < test.config

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

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