Модульное тестирование нескольких разных результатов одним методом

Question

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

Моя общая идея - попробовать что-то вроде

[TestCase("valid", Result="validasd", 
  Description = "Valid string test, expecting valid answer")]
[TestCase(null, ExpectedException = typeof(ArgumentNullException),
  Description = "Calling with null, expecting exception")]
[TestCase("", ExpectedException = typeof(ArgumentException), 
  Description = "Calling with an empty string, expecting exception")]
public string TestSubString(string value)
{
  return MethodUnderTest(value);
}

Это также рекомендуемое использование - без явного подтверждения, просто проверка возвращаемого значения? Или я должен придерживаться нормального способа или утверждать значение внутри метода?

Answer 1

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

Этот подход не работает, когда метод требует сложных параметров объекта, поскольку атрибут TestCase может принимать только примитивные типы в качестве входных параметров для передачи в метод.

Вы также можете рассмотреть возможность написания более типичного модульного теста, если:

1. другие разработчики в вашей команде не знакомы с этой техникой
2. сигнатура метода, который может изменить или приспособить больше параметров
3. если имеется более нескольких тестовых случаев или комбинаций значений для тестирования
4. вам нужно выполнить тесты в определенном порядке
5. вы хотите запустить свои тесты, используя ReSharper для Visual Studio (в настоящее время он не распознает атрибут TestCase)

Answer 2

Не лучше ли написать что-то подобное?

[Test]
public string TestSubString()
{
    Assert.AreEqual("validasd", MethodUnderTest("valid"));
    AssertEx.Throws<ArgumentNullException>(() => { MethodUnderTest(null); });
    AssertEx.Throws<ArgumentException>(() => { MethodUnderTest(""); });
}

Answer 3

Я думаю, что жюри все еще отсутствует в этом параметрическом тестировании - жесткие TDD-пользователи, вероятно, скажут, что это нарушает принцип «один утверждают на тест», и они, вероятно, правы. Самым важным в модульном тестировании является то, что при сбое теста вы можете быстро определить, что именно не удалось, какие входные данные вызвали его сбой, и воспроизвести его, повторно выполнив тот же тест. Хотя первые два могут не быть проблемой для такого рода структуры тестирования, третья, вероятно, будет (хотя с помощью достаточно умного инструмента вы сможете обойти это).

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

Answer 4

Для меня лучшим способом часто является тот, который заставляет вас писать меньше кода. Способ атрибута лучше на мой взгляд, потому что:

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

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

Answer 5

Я бы избежал этого. Это было бы чрезвычайно трудно поддерживать. У меня был бы один метод испытания для каждого случая.