Несколько устройств/утверждений на единицу измерения?

Question

Группа из нас (разработчики .NET) говорят об модульном тестировании. Не какая-либо структура (мы попали в MSpec, NUint, MSTest, RhinoMocks, TypeMock и т. Д.) - мы просто говорим в целом.

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

Есть ли что-нибудь подобное в тестировании на модуле .NET (состояние или поведение) сегодня?

Answer 1

посмотреть [TestCase (params)] в NUnit позволяет выполнять те же тесты с различными входами.

также для многократного утверждает одно, взгляд на OAPT (Одни утверждают на тест) бегун - который обещает пройти тест с Muliple утверждает и запустить каждый утверждают, как свой собственный тест: http://rauchy.net/oapt/

Answer 2

Одним из решений, которое вы могли бы сделать, является включение сценария в функцию SetUp.

В NUnit вы могли бы иметь метод, как:

частного class1 c1;

[SetUp()] 
private void Setup() 
{ 
c1 = new class1{Prop1 = 'A', Prop2= 'B'}; 
} 

Тогда есть два теста:

[Test()] 
private void Property1_Is_A 
{ 
    Assert.AreEqual('A', c1.Prop1); 
} 

[Test()] 
private void Property2_Is_B 
{ 
    Assert.AreEqual('B', c1.Prop2); 
} 

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

Тем не менее, есть некоторые веские аргументы против этого, поскольку индивидуальный тест должен настроить все, что ему нужно. Но это не жесткие правила.

Answer 3

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

Уже «стандартные» методы настройки/разведения помогают повторно использовать тестовый код. Кроме того, я считаю, что многие .Net-модульные тестовые среды реализуют те же или подобные функции своим Java-аналогам JUnit и TestNG, которые поддерживают, например. параметризованные тесты.

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

В моей интерпретации тестовый метод проверяет один вариант использования. Если есть ошибка утверждения, этот тест терпит неудачу, и есть веская причина исправить его как можно скорее. Нормальное состояние модульных тестов должно быть на 100% успешным, и в этом случае все утверждения во всех тестах проходят. Другими словами, неудачный тест должен быть скорее исключением, чем нормой; и я не слишком беспокоюсь об исключительных случаях. Если вы все еще беспокоитесь, вы всегда можете организовать ваши тестовые методы, чтобы содержать только одно утверждение.

Answer 4

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

Переменные входных переменных довольно распространены с использованием RowTest в MBUnit или теориях на xUnit.net. Google либо один из них, и вы найдете несколько примеров. У Бен Холла есть отличная статья об использовании Теории в xUnit.нетто: http://blog.benhall.me.uk/2008/01/introduction-to-xunitnet-extensions.html

Кроме того, мы не видим проспект неоднократное утверждает в данном тесте без сбоев раннего утверждают, угрожает тестирование позже утверждает

Имея множественным утверждает в один тест тонкий (и общий). Концепция, которая должна соблюдаться здесь, заключается в том, что одноблочный тест должен тестировать конкретное поведение или единую единицу кода. Если у вас есть 3 утверждения в одном модульном тесте, и первый из них терпит неудачу, независимо от того, проходят ли другие 2 или нет в этот момент, (а большинство тестирующих бегунов не будут запускать остальные утверждения в одном тесте после одного сбоя) , важно то, что один из неудачных утверждений.

Существует много мнений о том, должно ли быть более одного поведения/единицы кода, проверенных на каждый тест. Я предпочитаю одно поведение на тест по многим причинам. Самое главное, что когда один из этих тестов терпит неудачу, мне или кому-то еще придется вернуться и прочитать тест, чтобы увидеть, что именно происходит, и почему. Если нам нужно прочитать единичный тест, который делает больше, чем просто тестирование одного поведения, мы теряем время. Также намного проще убедиться, что вы пишете правильные тесты для своего кода при тестировании в небольших кусках. Я настоятельно рекомендую получить копию Roy Osherove's T he Art of Unit Testing.