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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

В NUnit у вас может быть такой метод:

частный класс1 с1;

[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 вызывается каждый раз перед выполнением теста. Я полагаю, вы могли бы сделать нечто подобное с конструктором, который вызывался бы один раз.

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