BDD с огурцом и rspec - когда это избыточно?

A Rails/специфичная для инструмента версия: Насколько глубоко ваши модульные тесты?

Сейчас я пишу:

  • Функции огурца (интеграционные тесты) - эти тесты против HTML/JS, возвращаемые нашим приложением, но иногда также проверяют другие вещи, такие как вызовы сторонним службам.
  • Тесты контроллера RSpec (функциональные тесты), первоначально только в том случае, если контроллеры имеют какую-либо значимую логику, но теперь все больше и больше.
  • Испытания модели RSpec (модульные тесты)

Иногда это совершенно необходимо; необходимо проверить поведение в модели, которая не является полностью очевидной или видимой для конечного пользователя. Когда модели сложны, их нужно обязательно проверять. Но иногда мне кажется, что тесты лишние. Например, вы тестируете метод foo, если он вызывается только bar, а bar проверен? Что делать, если bar - простой вспомогательный метод на модели, который используется и легко тестируется в функции огурца? Вы проверяете метод в rspec, а также на Cucumber? Я сталкиваюсь с этим, так как написание большего количества тестов требует времени и поддерживает несколько "версий" того, что является фактически одним и тем же поведением, что делает сохранение набора тестов более интенсивным, что, в свою очередь, делает изменения более дорогими.

Короче говоря, вы считаете, что есть время, когда писать только функции Cucumber достаточно? Или вы должны всегда проверять на каждом уровне? Если вы считаете, что есть серая область, каков ваш порог для "для этого нужен функциональный / unit test". С практической точки зрения, что вы делаете в настоящее время, и почему (или почему нет) вы считаете это достаточным?

РЕДАКТИРОВАТЬ: Вот пример того, что может быть "пробным переполнением" . По общему признанию, я смог напишите это довольно быстро, но это было полностью гипотетическим.

ОТВЕТЫ

Ответ 1

Хороший вопрос, с которым я недавно сталкивался, работая над Rails-приложением, также используя Cucumber/RSpec. Я стараюсь как можно больше протестировать на каждом уровне, однако, я также обнаружил, что по мере роста кодовой базы я иногда чувствую, что я повторяю себя бесполезно.

Используя тестирование "Вне помещения", мой процесс обычно выглядит примерно так: Сценарий огурца → Спецификация контроллера → Спецификация модели. Все больше и больше я нахожусь пропуская спецификации контроллера, поскольку сценарии огурца покрывают большую часть их функциональности. Я обычно возвращаюсь и добавляю спецификации контроллера, но он может чувствовать себя как-то вроде тяжелой работы.

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

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

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

Вот интересная статья, которую я вырыл из своих закладок, которые стоит прочитать: http://webmozarts.com/2010/03/15/why-not-to-want-100-code-coverage/

Ответ 2

Rails имеет хорошо протестированную базу кода, поэтому я бы избегал повторного тестирования материалов, которые описаны в этих шагах.

Например, если это не пользовательский код, бессмысленно тестировать результаты валидации на единичном и функциональном уровнях. Я бы тестировал их на уровне интеграции. Функции Cucumber действуют как спецификации для вашего проекта, поэтому хорошо указать, что вам нужна проверка для x и y, даже если реализация является объявлением одной строки в модели.

Ответ 3

Я тестирую сложную модель/lib-методы с rspec, а затем основную бизнес-логику в сети с огурцом, поэтому я уверен, что основные функции Интернета будут работать на 100%, тогда, если у меня будет больше времени и ресурсов, я тестирую все остальное.

Ответ 4

Легче писать простые спецификации для простых методов. Это гораздо проще, чем писать куки.

Если вы придерживаетесь своих методов просто - и сохраняйте свои спецификации просто - проверяя только логику внутри этого метода - вы найдете радость в модульном тестировании.

Если что-то лишнее, его тесты огурца. Если у вас есть хорошо протестированные модели и lib, ваше программное обеспечение должно работать.

Ответ 5

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