Хорошие примеры огурца в дикой природе?

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

Итак, на ваш взгляд, каковы наилучшие примеры фактических спецификаций огурца в крупных проектах?

Ответы

Ответ 1

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

Ответ 3

Это не прямой ответ, но я не согласен с предпосылкой в ​​вашем вопросе, но имею решение, поэтому я дам свое мнение в любом случае.

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

Это утверждение, я думаю, к сожалению, невозможно удовлетворить.

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

Однако здесь Аслак Хеллесёй, автор Cucumber, также принимающий общепринятое (но взаимоисключающее) мнение о том, что вам следует стремиться к сценариям, что имеет смысл с точки зрения "почему огурец вообще?"

Из приведенного выше "Обучающих колес", Aslak делает два примера сценариев, чтобы сильно контрастировать два стиля: многоразовые шаги vs сценарий.

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

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

Итак, я решил, что Cucumber в настоящее время сломан, и простой Capybara поверх вашей любимой модульной системы тестирования является наиболее гибким.

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

Альтернативный проект, который пытается устранить эти недостатки, Spinach, но проект не так активно. Посмотрите мои комментарии здесь об оценке "Шпинат против огурца" .

Ответ 4

Я искал проекты Cucumber. И на самом деле есть страница wiki в репозитории Cucumber со списком таких проектов (не все из них все еще используют Cucumber, хотя):

Проекты с использованием огурца:

Источник: https://github.com/cucumber/cucumber/wiki/Projects-Using-Cucumber

Ответ 5

Я рекомендую:

https://github.com/teambox/teambox/tree/dev/features

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

Обновление 2: я думаю, что поздно, я многому научился из-за следующих функций огурца, предоставляемых платной версией книги Object on Rails. Исходный код не является открытым исходным кодом, поэтому я не могу опубликовать его здесь или не смог найти ссылку на него.

Мой предпочтительный способ - сохранить язык функций близко к домену/деловому языку, а не выполнять определенные шаги или заполнять форму. Поэтому вместо того, чтобы иметь что-то подобное в моих функциях:

When I fill in "Name" with "XYZ

У меня будет моя функция:

When I create a project:
| name |
| xyz  |

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

Ответ 6

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

Я скажу, что мы сильно вдохновлялись шаблоном Page Objects в этих двух образцы. Мы находимся в центре тяжелого рефакторинга UI с командой UX. Использование объектов страницы сделало адаптацию тестов к этим изменениям достаточно простыми.

Ответ 7

Я бы хотел опубликовать те из нашего корпоративного репо (массивное внутреннее веб-приложение для Fortune 500).

Лучшее в дикой природе - это, вероятно, тесты Википедии:

https://github.com/wikimedia/qa-browsertests

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

У меня есть экспериментальный способ быстрого абстрагирования общих путей без циклов; должен, вероятно, очистить его и отправить его как запрос на тягу к Cheezy: https://github.com/cheezy/page-object

Ответ 8

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

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

Если вы правильно тестируете устройство, используйте Cucumber, чтобы описывать только счастливый путь вашего приложения, или только существенные недопустимые пути. Получите покрытие с помощью RSpec (или Xunit по выбору).

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