Как назвать и организовать модульные тесты, которые тестируют метод с несколькими параметрами? - PullRequest
Новая
       36

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

5 голосов
/ 10 марта 2011

Учитывая этот метод, который должен быть проверен: 

// Search the given value using the provided search options
// Return true if the searchValue was found; false otherwise 
bool Search(string searchValue, bool useExactSearch, bool useIndexing)

У меня есть 6 значимых searchValues ​​(одно с пунктуацией, одно с акцентированными символами, одно с переносами строк и т. Д.), Которые мне нужно проверить с каждой возможной комбинацией useExactSearch и useIndexing. Это означает 54 контрольных случая.

Как ты это делаешь? Вы действительно пишете 54 модульных теста? Если так, как вы их называете? Вы пишете тесты только для наиболее значимых случаев? Вы пишете единичные модульные тесты, которые перебирают таблицу значений параметров и ожидаемых результатов? Если я проведу одиночный модульный тест, то будет сложнее определить, какой случай нарушен, когда Continuous Integration сообщает об ошибке.

Ответы [ 3 ]

4 голосов
/ 10 марта 2011

Если вы используете NUnit (.Net), вы можете сделать это: 

[TestCase("John*",true, false, false)]
[TestCase("*user*",false, true, true)]
[TestCase(".",true, false, true)]
public void SearchTest(string param1, bool param2, bool param3, bool expectedResult)
{
    YourClass clazz = new YourClass();
    bool result = clazz.Search(param1, param2, param3);
    Assert.AreEqual(expectedResult, result);
}

NUnit Test Runner выполнит это 3 раза. И, как вы можете видеть здесь , отчет показывает все тестовые случаи отдельно, что помогает вам определить, кто нарушил сборку. Это, вероятно, доступно в большинстве платформ xUnit.

3 голосов
/ 10 марта 2011

В своей книге «Искусство модульного тестирования» Рой Ошеров рекомендует использовать это соглашение об именах: 

MethodUnderTest_ConditionUnderTest_ExpectedBehaviour()

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

Кстати, это не зависит от языка, но NUnit допускает параметризованные тесты, поэтому другие платформы модульного тестирования могут это делать. Это хороший промежуточный пункт между «одним трудным для понимания причиной сбоя» тестом и 54 «почти идентичными, с множеством тестов на дублирование».

0 голосов
/ 10 марта 2011

Следует писать тесты, по крайней мере, для значимых тестовых случаев, и тесты могут быть названы в соответствии с тестовым примером, таким как TestSeachForPunctuation, TestSeachForAccentedChars, TestSeachForLineBreaks.

...