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

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

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

    ...
}

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

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

TestCase 'MyProject.MyTests.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 }
            };
        }
    }

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


parameters testing nunit testdriven.net
person Thomas Levesque    schedule 05.09.2009    source источник
comment
Я думаю, если вы сделаете это, у вас возникнут проблемы с автоматическим запуском тестов в среде непрерывной интеграции (CI).   -  person 7wp    schedule 05.09.2009
comment
Ты совершенно прав. Однако это небольшой проект сообщества, поэтому CI на самом деле не проблема, по крайней мере, на данный момент.   -  person Thomas Levesque    schedule 05.09.2009

Ответы (4)


arrow_upward
2
arrow_downward

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

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

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

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

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

person Juri    schedule 10.09.2009
comment
Спасибо, но опять же, это не решает мою проблему ... Как мне запустить тест, требующий учетных данных? Я не хочу помещать свое личное имя пользователя и пароль в код, которым будут делиться с другими ... - person Thomas Levesque; 10.09.2009
comment
В таком случае используйте фиктивные учетные данные. Какую логику ваш модульный тест должен охватывать s.t. вам нужна обработка учетных данных и т. д.? - person Juri; 10.09.2009
comment
О, теперь я прочитал ваш отредактированный пост. Не могли бы вы просто использовать фиктивные учетные данные. Тестовый пользователь + проход, который имеет право доступа к тому, чего вам нужно достичь? Хотя я не совсем уверен, действительно ли именно то, чего вы хотите достичь, следует тестировать с помощью модульного теста. Проверьте это: stackoverflow.com/questions/1257560/ - person Juri; 10.09.2009
comment
Тестируемый мной компонент подключается к форуму VBulletin для получения файлов cookie аутентификации. Может быть, я мог бы создать фиктивную учетную запись ... или, возможно, вы правы, и это даже не должно быть модульным тестом;) - person Thomas Levesque; 10.09.2009
comment
Поймите ... хорошо, что всегда можно обсудить, что является модульным тестом, а что нет. В вашем случае я бы сказал, что это не совсем то, что я бы зафиксировал с помощью модульного теста. Что бы я сделал, так это предоставить фиктивный файл cookie аутентификации и каким-то образом внедрить его, чтобы имитировать вызов VBulletin. Таким образом, я бы проверил, что моя логика делает с правильным файлом cookie, а что с неправильным. На мой взгляд, это то, что нужно уловить с помощью модульного теста. - person Juri; 10.09.2009
comment
Юри и Дж.Р. Гарсия правы. Вам нужны автоматические тесты без участия оператора - таким образом вы можете запускать их с сервера сборки и т. Д. Способ сделать это - использовать внедрение зависимостей с фиктивным (заглушкой) объектом, который обрабатывает вашу аутентификацию. В реальном приложении вы вводите настоящую схему аутентификации (реализуя тот же интерфейс). - person TrueWill; 24.09.2009

arrow_upward
22
arrow_downward

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

[TestCase("User1", "")]
[TestCase("", "Pass123")]
[TestCase("xxxxxx", "xxxxxx")]
public void TestLogin(string userName, string password)
{
    // ...
}
person Naeem Sarfraz    schedule 13.09.2011
comment
+1. Это намного лучше, чем выбранный ответ, поскольку он обрабатывает внедрение зависимостей прямо в параметрах TestCase () вместо того, чтобы игнорировать аргументы в методе. к сожалению, я не думаю, что в MS Unit Test есть что-то подобное, просто Nunit - person DeepSpace101; 19.11.2012
comment
Это правильный и короткий ответ. Неважно, хорошая это практика или плохая. - person Mário Meyrelles; 24.03.2015
comment
Отметьте это как правильный ответ. Это отвечает на вопрос, и для меня это неплохая практика в целом использовать параметры. Для паролей я был бы менее склонен. - person Rexxo; 04.10.2016

arrow_upward
2
arrow_downward

Я думаю, вы можете решить эту проблему, используя плагин 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);
 }
}
person 7wp    schedule 10.09.2009
comment
Спасибо за Ваш ответ. Я думаю, что этот плагин устарел из-за нового TestCaseAttribute в NUnit 2.5 (nunit.org/index .php? p = testCase & r = 2.5). В любом случае, это не решает мою проблему: я не хочу жестко кодировать свои учетные данные. Я хочу, чтобы при запуске теста предлагалось ввести его вручную - person Thomas Levesque; 10.09.2009
comment
Ах хорошо. Я неправильно понял. Приятно знать о TestCaseAttribute :) - person 7wp; 10.09.2009

arrow_upward
0
arrow_downward

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

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

nunit tests.dll < test.config

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

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

person kapex    schedule 19.02.2012