Что тестировать при написании модульных тестов?

Question

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

В настоящее время мы генерируем все наши базовые классы, используя Codesmith, которые полностью основаны на таблицах в базе данных. Мне интересно узнать о преимуществах создания тестовых примеров с этими базовыми классами? Являются ли эти плохие методы тестирования?

Это приводит меня к окончательному вопросу о моем посту. Что мы тестируем при использовании Unit Tests?

Мы тестируем примеры, которые мы знаем, что хотим? или мы проверяем примеры, которые нам не нужны?

Их могут быть методы, которые имеют несколько способов устранения и множественные способы успеха, как мы узнаем, когда остановиться?

Возьмите функцию суммирования, например. Дайте ему 1,2 и ожидайте 3 в единственном модульном тесте. Как мы знаем, что 5,6 не вернутся? 35?

Вопрос резюмировать

• Создание модульных тестов (хороший/плохой)
• Что/Сколько мы тестируем?

Answer 1

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

class Adder { public int Add(int x, int y) { return x + y; } } 

и соответствующий тест блок

[Test] 
public void Add_returns_that_one_plus_two_is_three() { 
    Adder a = new Adder(); 
    int result = a.Add(1, 2); 
    Assert.AreEqual(3, result); 
} 

, то это дает вам некоторые (но не 100%) уверенность в том, что метод испытуемый ведет себя соответствующим образом. Это также дает вам некоторую защиту от нарушения кода при рефакторинге.

Что мы тестируем при использовании модульных тестов?

Фактическое поведение ваших общедоступных методов против ожидаемого (или указанного) поведения.

Мы тестируем примеры, которые мы знаем, что хотим?

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

Answer 2

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

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

Answer 3

1) Для начала я бы рекомендовал вам протестировать основную логику вашего приложения.

2) Затем используйте инструмент покрытия кода в vs, чтобы узнать, используется ли весь ваш код в тестах (все ветви if-else, условия случая вызывают). Это какой-то ответ на ваш вопрос об испытании 1 + 2 = 3, 5 + 6 = 35: когда код закрыт, вы можете чувствовать себя в безопасности с дальнейшими экспериментами.

3) Это хорошая практика, чтобы покрыть 80-90% кода: все остальные работы, как правило, unefficient: геттеры-сеттеры, обработка исключений 1-линия и т.д.

4) Узнайте о разделении проблем ,

5) Испытания модуля поколений - попробуйте, вы увидите, что вы можете сохранить красивые строки кода, записывая их вручную. Я предпочитаю генерировать файл с помощью vs, а затем записывать остальные TestMethods самостоятельно.

Answer 4

Что тестировать: все, что когда-либо случилось.

Если вы обнаружили ошибку, напишите тест на поведение с ошибкой до вы исправите код. Затем, когда код работает правильно, тест пройдет, и у вас будет еще один тест в вашем арсенале.

Answer 5

Вам UnitTest вещи, где вы

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

Так что в вашем примере это не имеет особого смысла для проверки сгенерированных классов. Вместо этого протестируйте генератор.

Рекомендуется проверять основные варианты использования (для чего была спроектирована испытанная функция). Затем вы проверяете основные ошибки. Затем вы пишете тесты для угловых случаев (т. Е. Нижняя и верхняя границы). Необычные случаи ошибок, как правило, так сложно произвести, что нет смысла тестировать их.

Если вам нужно проверить большой набор наборов параметров, используйте тестирование, основанное на данных.

Сколько вещей, которые вы тестируете, - это вопрос усилий против возврата, так что это действительно зависит от отдельного проекта. Обычно вы пытаетесь следовать правилу 80/20, но могут быть приложения, в которых вам нужно больше тестового покрытия, потому что отказ будет иметь очень серьезные последствия.

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

Answer 6

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

Answer 7

Есть три основных события, которые я тестирую для: мин., Макс., И где-то между мин. И макс.

И в соответствующих случаях две крайности: ниже min и выше max.

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