Я должен записать интеграционный тест или модульный тест?
У меня есть функция, которая сохраняет фотографии (сохраненный в базе данных, приложение дает пользовательскую опцию сохранить в каталоге) к данному каталогу. Теперь, это не работало правильно. Я просто зафиксировал его. Теперь, я должен записать модульный тест или интеграционный тест на функцию?
5 ответов
Для вашего случая, вы хотите написать интеграционный тест , чтобы покрыть упомянутый вами сценарий. У меня есть полный пост на эту тему. Однако, вот краткая версия, специфическая для вашего вопроса:
В своей книге Искусство юнит-тестирования Рой Ошероув описывает ключевой принцип, согласно которому юнит-тест должен быть "заслуживающим доверия". На первый взгляд это кажется довольно очевидным. Однако, это подчеркивает некоторые ключевые различия между юнит-тестом и интеграционным тестом.
С помощью надежного теста вы должны быть в состоянии доверять результатам в 100% случаев. В случае неудачи теста необходимо быть уверенным в том, что код сломан и должен быть исправлен. Вы не должны спрашивать такие вещи, как "Была ли база данных повреждена?", "Была ли строка соединения в порядке?", "Была ли изменена хранимая процедура?". Задавая эти вопросы, вы показываете, что не можете доверять результатам и, скорее всего, у вас плохо разработан "юнит-тест".
Поскольку в вашем сценарии описывается ситуация со схожими множественными зависимостями, вы хотите покрыть ее интеграционным тестом. Опять же, для более подробной информации, смотрите и мой полный пост здесь .
Удачи!
.Интеграционные тесты и юнит-тесты имеют различную область применения и назначение:
- Юнит-тесты проверяют небольшие фрагменты кода (например, функцию) изолированно от остальной части программы, в идеале охватывая все возможные краевые случаи (например, исключения, нулевые параметры и т.д.)
- Интеграционные тесты проверяют целое приложение с точки зрения конкретного случая использования. Они никогда не могут охватить все краевые случаи, но могут выявить проблемы взаимодействия между частями кода и соединяющим их клеевым кодом, которые юнит-тесты часто пропускают
Для синус-функции, на самом деле, можно иметь только юнит-тест, и он должен быть. Но можно иметь и интеграционный тест, который показывает, что при нажатии пользователем определенной кнопки в каталог записывается фотография, которую можно открыть и в программе
.Одни называют тест DAO интеграционным тестом, другие - юнит-тестом.
Как бы вы это ни называли, я бы сказал, что вы должны иметь юнит-тест для всей функциональности DAO и интеграционный тест для поведения front-to-back, воплощённого в сценарии использования, который говорит: "дайте пользователю возможность сохранить в файловую систему". Я бы предложил интеграционные тесты для обоих сценариев, так как похоже, что оба варианта возможны в вашей системе.
.Я думаю, это зависит от источника вашей проблемы. Если сама функция может иметь некоторые проблемы в различных сценариях, вы можете провести юнит-тесты, чтобы протестировать этот сценарий над вашей функцией. Если интеграция вашей функции и других частей программы может вызвать некоторые проблемы, то вам следует подумать об интеграционном тесте. Иногда функция, подобная вашей, может нуждаться в некоторых внешних ресурсах для выполнения своей работы. Неплохая идея иметь несколько юнит-тестов, чтобы посмотреть, что произойдет, если некоторые из этих ресурсов будут недоступны
.- Интеграционные тесты помогают проверить, работает ли ваше программное обеспечение правильно.
- Юнит-тесты помогают найти причины поломки вашего программного обеспечения.
Юнит-тесты в некоторой степени также способствуют достижению первой цели. Плюс у них есть пара преимуществ:
- Обычно гораздо дешевле написать и запустить модульный тест с гораздо меньшим объемом.
- Легче получить покрытие для комбинаторного взрыва состояний ваших компонентов с помощью модульных тестов, чем с помощью интеграционных тестов. Допустим, у вас есть установка, включающая три компонента. Каждый из них имеет 3 различных состояния. Тогда интеграционное тестирование всей установки будет включать проверку 3 * 3 * 3 = 27 состояний. При модульном тестировании отдельных компонентов потребуется проверить 3 + 3 + 3 = 9 условий. (Это слишком упрощенно, но вы, надеюсь, поймете суть.)
Из-за этого модульные тесты обычно более популярны, чем интеграционные. Однако без интеграционных тестов действительно не обойтись. Интеграционные тесты должны быть краеугольным камнем, используемым для приемки вашего программного обеспечения. Наличие модульных тестов лишь доказывает, что у вас есть куча вещей, делающих что-то. Интеграционный тест доказывает, что у вас есть работающее программное обеспечение.