Практика BDD с интеграционными тестами - мне тоже нужны юнит-тесты?

Question

В настоящее время мой процесс разработки выглядит следующим образом:

1. Я описываю ожидаемое поведение как интеграционный тест с использованием WebRat
2. Я пишу код Ruby on Rails, чтобы обеспечить такое поведение, поэтому прохожу тест
3. Я выполняю рефакторинг, гарантируя, что тесты все же пройдут в конце процесса
4. Я пишу следующий интеграционный тест

Мне кажется, что по определению мои интеграционные тесты тестируют каждую модель, контроллер и представление, которые я могу создать. На самом деле, я что-то упускаю, не написав модульные тесты тоже?

Answer 1

Я на самом деле довольно сочувствую вашей точке зрения здесь. Я люблю Cucumber и Я люблю RSpec - и я использую их обоих, но не всегда в одном и том же коде. Например, в настоящее время я редко пишу примеры RSpec для контроллеров Rails и почти никогда не пишу спецификации представлений. Большинство моих контроллеров очень похожи и не сильно отличаются от «стандартного» шаблона контроллера, который уже хорошо протестирован в собственных модульных тестах Rails. Повторная проверка того же поведения не приносит много пользы за время, необходимое для насмешек над всеми моделями. С Cucumber на уровне интеграции я могу пропустить эту насмешку и получить необходимую проверку, которую я ищу. Тестирование представлений в Cucumber выполняется гораздо более прозрачно. ( Тогда я должен увидеть "foo" и т. Д.)

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

Как эвристик, я бы посоветовал вам сильно рассмотреть вопрос о написании модульного теста в любое время, когда на любой из следующих вопросов можно ответить "Да":

• Код, который я пишу, более сложен?
• Этот код существует главным образом для ответа на другой код?
• Это существующий код, который я рефакторинг (который еще не прошел модульный тест)?
• Нашел ли я ошибку в этом коде? (Если это так, напишите модульный тест, прежде чем исправлять его, чтобы он никогда не пробирался снова.)
• Должен ли я более десяти секунд думать о наиболее элегантном способе реализации этого кода?
• Мое чувство Паучьего покалывает?

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

Answer 2

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

Answer 3

Есть ли у вас какие-либо грабли? Пользовательский код capistrano? Cron методы? API? Monkeypatches? Как насчет интеграции Flex или iPhone? Работник?

В типичном приложении на Rails есть много кода, который не выполняется HTML-интерфейсом. Так что нет, если ваше приложение невероятно простое, вебратных тестов будет недостаточно.