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

Question

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

Так что, по вашему мнению, каковы лучшие примеры реальных спецификаций Cucumber вкрупные проекты?

Answer 1

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

Answer 2

Вы можете прочитать особенности самого Огурца, ребята должны знать, что они делают:

https://github.com/cucumber/cucumber-ruby/tree/master/features

Answer 3

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

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

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

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

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

Из вышеприведенной «Тренировочных колес», Аслак делаетдва примера сценария, чтобы резко противопоставить два стиля: многократно используемые шаги против специфичные для сценария .

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

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

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

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

Альтернативный проект, который пытается устранить эти недостатки, - * 1035.* Шпинат , но проект не так уж активен. Смотрите мои комментарии здесь об оценке Spinach vs Cucumber .

Answer 4

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

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

• Gemcutter
• Клиренс /generators/clearance_features/templates/features/
• WebJam /features/
• Redcar /plugins/*/features
• ювелир /features
• Джекилл /features
• CarrierWave /features/
• RadiantCMS
• OERPScenario (связан с OpenERP)
• WontoMedia /features/
• Каталог Rails
• Бульон
• Подтяжки Heroku
• TimeFliesBy
• Диаспора
• Шеф-повар

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

Answer 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  |

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

Answer 6

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

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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