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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

Сверху моей головы

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

неудачный тест → код → прохождение теста → рефактор → повтор

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

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

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

Ответ 8

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

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

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

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