Почему функциональных тестов недостаточно? Что предлагают юнит-тесты?

Question

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

Я пытался объяснить, но не очень далеко, и думал, что вы, ребята, могли бы сделать лучше. ;-) Итак ...

Какие есть веские причины для модульного тестирования кода, который не предлагают функциональные тесты? Какие опасности существуют, если у вас есть только функциональные тесты?

Редактировать # 1 Спасибо за все отличные ответы. Я хотел бы добавить, что под функциональными тестами я имею в виду не только тесты всего продукта, но также тесты на модулях продукта, но не на низком уровне модульного теста с имитацией в случае необходимости и т. Д. Обратите внимание, что наши функциональные тесты являются автоматическими и работают непрерывно, но они занимают больше времени, чем модульные тесты (что является одним из больших преимуществ модульных тестов).

Мне нравится пример "кирпич против дома". Полагаю, что мой ведущий разработчик говорит, что тестирование стен дома достаточно, вам не нужно тестировать отдельные блоки ...: -)

Answer 1

с макушки головы

• Юнит-тесты повторяются без усилий. Пишите один раз, выполняйте тысячи раз, не требуя человеческих усилий, и намного быстрее, чем вы получаете при функциональном тесте
• Модульные тесты тестируют небольшие блоки, поэтому сразу указывайте на правильный «сектор», в котором возникает ошибка. Функциональные тесты указывают на ошибки, но они могут быть вызваны множеством модулей, даже в кооперации.
• Я бы вряд ли назвал изменение интерфейса "внутренним рефакторингом". Изменения интерфейса имеют тенденцию ломать большую часть кода и (на мой взгляд) форсировать новый тестовый цикл, а не ни один.

Answer 2

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

функциональные тесты предназначены для бизнеса, чтобы увидеть, выполняет ли код то, что они просили

Answer 3

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

функциональные тесты предназначены для бизнеса, чтобы увидеть, выполняет ли код то, что они просили

модульные тесты проверяют, правильно ли вы изготовили кирпичи

функциональные тесты проверяют, что дом отвечает потребностям клиента.

Это разные вещи, но последнее будет намного проще, если первое было выполнено.

Answer 4

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

Answer 5

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

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

Answer 6

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

• Модульные тесты работают быстрее. Если вы когда-либо работали над большим проектом, в котором тестовый набор занимает несколько часов, вы можете понять, почему быстрые тесты важны.
• По моему опыту, функциональные тесты, скорее всего, будут нестабильными. Например, иногда безголовый браузер capybara-webkit по какой-то причине просто не может добраться до вашего тестового сервера, но вы перезапускаете его, и он работает нормально.
• Модульные тесты легче отлаживать. Предполагая, что модульный тест обнаружил ошибку, проще и быстрее точно определить, где именно проблема.

С другой стороны, если вы решите просто оставить свои функциональные тесты, а не добавить какие-либо юнит-тесты

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

Answer 7

В TDD / BDD , для написания программы необходимы юнит-тесты. Процесс идет

провал теста -> код -> прохождение теста -> рефакторинг -> повтор

В статье также упоминаются преимущества TDD / BDD. В итоге:

• Очень близок к тому, чтобы исключить использование отладчика (сейчас я использую его только в тестах и ​​очень редко для них)
• Код не может оставаться грязным дольше, чем несколько минут
• Примеры документации для встроенного API
• Усилие слабого сцепления

Ссылка также содержит (глупый) пошаговый пример TDD / BDD, но она есть в PowerPoint (ew), поэтому здесь - это html-версия.

Answer 8

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

В чистом XP / Agile все требования предъявляются на основе тестов, которые будут выполнены для приложения

• Функциональные тесты - Генерация функциональных требований.
• Модульные тесты - создание функций или требований к объекту.

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

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