Что протестировать при записи Модульных тестов?
Я хочу начать поблочное тестирование наше приложение, потому что я полагаю, что это - первый шаг к развитию хороших отношений с тестированием и позволит мне переходить в другие формы тестирования, самого интересного BDD с Огурцом.
Мы в настоящее время генерируем все наше использование Базовых классов Codesmith, которые базируются полностью на таблицах в базе данных. Мне любопытно относительно преимуществ генерации тестовых сценариев с этими Базовыми классами? Это плохое тестирует методы?
Это приводит меня к окончательному вопросу моего сообщения. Что мы тестируем при использовании Модульных тестов?
Мы тестируем примеры, мы знаем, что хотим выйти? или мы тестируем примеры, которые мы не хотим?
Их могут быть методы, которые имеют несколько способов Перестать работать и несколько способов Успеха, как мы знаем, когда остановиться?
Возьмите функцию Подведения итогов, например. Дайте его 1,2 и ожидайте 3 в единственном модульном тесте.. как мы знаем, что 5,6 не возвращается 35?
Резюме вопроса
- (Хорошие/Плохие) тесты электростанции
- Что/Насколько мы тестируем?
7 ответов
Цель модульных тестов - дать вам уверенность (но только в особых случаях это дает вам уверенность), что фактическое поведение ваших общедоступных методов соответствует ожидаемому поведению. Таким образом, если у вас есть класс 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%) уверенность в том, что тестируемый метод ведет себя надлежащим образом. Это также дает некоторую защиту от взлома кода при рефакторинге.
Что мы тестируем при использовании модульных тестов?
Фактическое поведение ваших общедоступных методов в сравнении с ожидаемым (или указанным) поведением.
Тестируем ли мы примеры, которые, как нам известно, мы хотим получить?
Да, один из способов убедиться в правильности вашего метода - это ввести некоторый ввод с известным ожидаемым результатом, выполнить открытый метод на входе и сравнить фактический выход к ожидаемому выходу.
Я также начинаю процесс более последовательного использования модульных тестов и обнаружил, что самой большой задачей модульного тестирования является структурирование моего кода для поддержки тестирования. Когда я начинаю думать о том, как писать тесты, становится ясно, где классы стали чрезмерно связанными до такой степени, что сложность «модуля» затрудняет определение тестов. Я трачу на рефакторинг своего кода столько же или больше времени, сколько на написание тестов. Как только границы между тестируемыми модулями становятся более четкими, вопрос о том, с чего начинать тестирование, решается сам собой; начните с ваших мельчайших изолированных зависимостей (или, по крайней мере, тех, которые вас беспокоят) и продвигайтесь вверх.
Я тестирую три основных события: мин, макс и где-то между мин и макс.
И, где это уместно, два крайних значения: ниже минимального и выше максимального.
Существуют очевидные исключения (например, некоторый код может не иметь минимального или максимального значения), но я обнаружил, что модульное тестирование для этих событий является хорошим началом и фиксирует большинство «общих» проблем с кодом.
Что тестировать: все, что когда-либо пошло не так.
Если вы обнаружите ошибку, напишите тест на ее поведение , прежде чем исправите код.Затем, когда код работает правильно, тест будет пройден, и в вашем арсенале появится еще один тест.
Начните с требований и напишите тесты, которые проверяют ожидаемое поведение. С этого момента количество других сценариев, которые вы тестируете, может зависеть от вашего графика или, возможно, от того, что вы распознаете сценарии неугостия, которые особенно рискованны.
Вы можете рассмотреть возможность написания тестов на неудачу только в ответ на обнаружение дефектов, которые вы (или ваши пользователи) (идея заключается в том, что вы пишете тест, который проверяет исправление дефекта до того, как вы фактически исправите дефект, так что ваш тест потерпит неудачу, если этот дефект будет повторно введен в ваш код в будущей разработке).
Вы проводите модульное тестирование, где
- хотите убедиться, что ваш алгоритм работает
- хотите защитить себя от случайных изменений в будущем
Таким образом, в вашем примере это будет не имеет особого смысла тестировать сгенерированные классы. Вместо этого проверьте генератор.
Рекомендуется сначала протестировать основные варианты использования (для чего была разработана тестируемая функция). Затем вы проверяете основные случаи ошибок. Затем вы пишете тесты для угловых случаев (т.е. нижней и верхней границ). Необычные случаи ошибок обычно настолько сложны, что их модульное тестирование не имеет смысла.
Если вам нужно проверить большой диапазон наборов параметров, используйте тестирование на основе данных.
Сколько вещей вы протестируете - это вопрос усилий или отдачи, так что это действительно зависит от конкретного проекта. Обычно вы пытаетесь следовать правилу 80/20, но могут быть приложения, в которых вам нужно больше тестового покрытия, потому что сбой будет иметь очень серьезные последствия.
Вы можете значительно сократить время, необходимое для написания тестов, если используете подход, основанный на тестировании (TDD). Это потому, что код, который написан без учета тестируемости, намного сложнее, а иногда почти невозможно протестировать. Но поскольку в жизни нет ничего бесплатного, код, разработанный с помощью TDD, имеет тенденцию быть более сложным.
1) Для начала я рекомендую вам протестировать основную логику вашего приложения.
2) Затем используйте инструмент покрытия кода в vs, чтобы увидеть, используется ли весь ваш код в тестах(вызываются все ветви if-else, условия case). Это своего рода ответ на ваш вопрос о тестировании 1+2 = 3, 5 + 6 = 35: когда код покрыт, вы можете чувствовать себя в безопасности при дальнейших экспериментах.
3)Хорошей практикой является покрытие 80-90% кода: остальная часть работы обычно неэффективна: getters-setters, обработка 1-строчных исключений и т. д.
4) Узнайте о разделении проблем.
5) Генерация модульных тестов - попробуйте, вы увидите, что вы можете сохранить красивые строки кода, написав их вручную. Я предпочитаю генерировать файл с vs, а затем записывать остальные TestMethods самостоятельно.