Распространено ли писать интеграционные тесты перед написанием юнит-тестов?

Question

Обычно пишут интеграционные тесты перед написанием юнит-тестов?Это нормально, хорошая идея или лучшая практика?

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

Я на правильном пути?

EDIT

Спасибо всем за ваши ответы.Я только что опубликовал аналогичный / связанный вопрос .

Answer 1

Когда мне поручается разработка с использованием стороннего API, первое, что я делаю, - это создаю прототип (интеграционный тест, если хотите), чтобы получить ожидаемый / желаемый результат. Затем я создаю несколько модульных тестов, которые реализуют это ожидание, и преобразую прототип в реальный код, который я буду использовать для продвижения вперед.

Так что да, ИМО, это довольно типично. Это не может быть TDD в чистом смысле, но я в порядке с этим.

Answer 2

Я на правильном пути?

Используете ли вы тесты для разработки? то есть TDD?

Если это так, вы на правильном пути.

«Интеграционный тест» и «Модульный тест» - мутные определения. Ученые могут ломать волосы, пытаясь найти способы их различить.

Не тратьте время на укладку волос.

Сначала напишите тесты.

Answer 3

Я не уверен, насколько это распространено, но я определенно видел, как тестирование более высокого уровня рекомендуется в качестве первого шага.Например, в растущем объектно-ориентированном программном обеспечении, управляемом тестами , первое, что автор рекомендует, - это создание леса функциональных / приемочных тестов, а затем начало разработки, написав приемочные тесты высокого уровня (верхушка треугольника тестирования, с интеграционными тестами в середине и юнит-тестами внизу, так что на самом деле это тот же принцип).

В итоге получается что-то вроде:

• Запись несостоявшегося функционального теста для функции X
• Запись несостоявшегося модульного теста
• Выполнение прохождения модульного теста
• Проходит ли функциональный тест?Если нет, напишите еще один неудачный модульный тест и внедрите следующий блок.

Answer 4

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

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

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

Answer 5

Я считаю, что это зависит от:

1. Какую третью сторону вы используете.

   Я думаю, что нет смысла проверять, правильно ли INSERT запрос вставляет строки в SQL Server, но вы можете проверить, получает ли какой-то непопулярный веб-сервис ожидаемый результат как часть вашего теста

2. Насколько сложно настроить внешнюю зависимость и сколько она стоит.

   Я не могу представить интеграционный тест, в котором для проверки используется платежный процессор, если транзакция на сумму свыше 1000 долларов США прошла успешно:)