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

Question

A Rails / инструментальная версия: Насколько глубоки ваши юнит-тесты?

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Если это не ваш сценарий, не используйте огурец, потому что он вам не нужен. Используйте rspec и capybara для проверки кода JS и интеграционных тестов.

Answer 5

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

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

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

Answer 6

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