Что нужно сделать, чтобы улучшить свои навыки модульного тестирования
Тесты имеют решающее значение для любого программного обеспечения. Особенно модульные и интеграционные тесты.
Вы написали алгоритм, провели несколько тестов вручную, он работает. Ты не прав. Отдельные компоненты могут сломаться, или может произойти крайний случай.
Вы хороший разработчик, не допускаете ошибок. Создание модульных тестов и интеграционных тестов снижает риск сбоев.
Имея это в виду, давайте перейдем к трем советам, которые помогут улучшить ваше модульное тестирование.
Вдохновение для этой статьи пришло после чтения «Искусство модульного тестирования».
Вы создаете ремонтопригодные тесты?
Никто не меняет тесты, которые сложно поддерживать. Никто. Вам необходимо подготовить почву для написания чистых и простых в использовании тестов.
Вы всегда должны тестировать контракт класса. Есть внутренние, частные методы, которые нужно изменить. Открытые методы должны открывать интерфейс для класса и не должны меняться в поведении.
Тестирование частных методов подвержено ошибкам. Вот почему вам следует избегать этих тестов.
«Тестирование функциональности частных методов может привести к сбою тестов, даже если общая функциональность верна».
- Рой Ошеров
Делать все методы общедоступными - не лучший вариант. Наличие большого количества общедоступных методов нарушает принцип единой ответственности.
«Клиентов не следует заставлять зависеть от интерфейсов, которые они не используют».
- Роберт К. Мартин
Имея это в виду, отделите свой интерфейс. Прочтите эту хорошую статью, чтобы начать с разделения интерфейсов.
Суть в том, чтобы не забивать ваши интерфейсы методами, которым там не место. Разделение приводит к лучшему модульному тестированию, поскольку у вас есть небольшие фрагменты кода для тестирования.
Вы изолируете свои тесты?
Модульное тестирование должно следовать принципам белого ящика. Покройте положительные и отрицательные потоки и охватите все ветви принятия решений.
Плохая тестовая изоляция приводит к нестабильным, нестабильным тестам. Подсказки о том, что создает нестабильные тесты:
Потоковое тестирование - разработчик пишет тесты, которые должны выполняться в определенном порядке, чтобы они могли тестировать выполнение потока, большой вариант использования, состоящий из множества действий, или тест полной интеграции, где каждый тест представляет собой один шаг в тот полный тест.
Ленивость при очистке. Разработчик ленив и не возвращает никаких данных о состоянии, которое ее тест мог вернуть в исходную форму.
- отрывок из книги «Искусство модульного тестирования»
Мы все виноваты в вышесказанном. Процесс тестирования в модульных тестах, а не в интеграционных тестах. Загромождение состояния модульного теста и организация тестов для прохождения.
Боритесь с ними, изменив свои привычки. Очистите базу данных после завершения тестирования. Инициализация сразу после тестирования. Переместите потоковое тестирование в интеграционные тесты.
Вы проверяете, что может пойти не так?
Мы оптимистичные разработчики и никогда не думаем, что что-то может пойти не так. Что ж, это неправильно само по себе. Сначала нам нужно подумать о наихудшем сценарии.
Написав много строк кода, я заметил, что мы пропускаем тестирование негативного сценария. Это приводит к ошибкам и плохой работе. Начните кодирование с тестовых примеров, описывающих негативные сценарии.
Например, вам нужно создать метод, который делит два числа. Начните с отрицательных тестовых случаев.
@Test(expected = IllegalArgumentException.class)
public void divide_OneNumberIsNull_ThrowException(){...}
@Test(expected = IllegalArgumentException.class)
public void divide_BothNumbersAreNull_ThrowException(){...}
@Test(expected = IllegalArgumentException.class)
public void divide_DivideByZero_ThrowException(){...}
Выполнение сначала негативных сценариев откроет новые идеи. Вы увидите несколько новых сценариев, которые могут произойти. Разработка тестов всегда окупается.
Спасибо за прочтение!
