Я собираюсь попробовать перефразируйте то, о чем вы просите здесь, в надежде, что это прояснит некоторые вещи.
Мы недавно начали использовать BDD для написания наших требований ... Теперь мы думаем о написании наших тестовых примеров с BDD.
Мы недавно начали использовать примеры, чтобы уточнить наши требования ... теперь мы думаем автоматизировать эти примеры.
Когда я ищу в Интернете лучшие практики, я вижу много разных вариантов написания.
Когда я ищу в Интернете, я вижу много разных вариантов контекста, события и результата.
(Это не только в письменной форме;. Это в разговоре, что приводит к написанию этой причине вы получаете изменение, потому что разговор действительно нечеткой.)
Проблема почти все примеры очень простые случаи
Проблема в том, что в прежние времена ранние усыновители, как я, использовали такие вещи, как логин в качестве примера.
Мы ошибались. Простые примеры на самом деле не помогают понять BDD. Вся красота заключалась в том, что, когда мы разговаривали с заинтересованными сторонами, которые понимали проблему (кто может быть экспертами в области безопасности или инфраструктуры, например, это касается не только бизнес-экспертов), мы узнали что-то. Вот a talk о том, что мы сделали неправильно в первые дни BDD; вы сталкиваетесь со стоимостью некоторых из них. Сожалею.
Я написал a whole blog post по 3 аспектам BDD: исследование, спецификация и испытание на примере. Большинство людей сосредотачивается на 2-м и 3-м из них, но 1-е является неявным. Изучение важно, и разговоры вокруг сценариев - действительно дешевый способ сделать это!
Мы хотели бы написать сценарии, которые включают в себя несколько действий, несколько системных выходов (предупреждения, ошибки и т. Д.) И несколько выходов ... Причина, по которой у нас такая длинная история, - это общий сценарий, может случиться, и мы хотим убедиться, что пользователи смогут вернуться к счастливому пути.
Мы хотим, чтобы проверить полные поездки клиента, чтобы убедиться, что наша система не является, по крайней мере использовать, независимо от того, что еще происходит.
Таким образом, если вы хотите использовать инструменты BDD, такие как Cucumber, чтобы написать целое автоматическое путешествие клиентов с полным стеком, а не один пример одного аспекта поведения (то, что мы называем сценарием). .. это не BDD.
Однако, это is по-прежнему очень хорошая идея. Это не BDD, но это не значит, что это плохо. Я работал с несколькими организаторами, которые сделали это и выиграли от этого. (Может быть, это должно быть имя.)
Вот подсказки и советы я могу дать вам на основе этого опыта:
Do не использовать их в качестве регрессионных тестов! Попытка пройти каждое путешествие - это экспоненциальное усилие; забудь это. Выберите несколько путешествий (3 за идеальный сеанс кажется довольно типичным) и попытайтесь выбрать разные, но типичные варианты для клиентов. Не используйте их для проверки краев. Вы просто проверяете, что ваши основные поездки клиентов все еще сшиты вместе.
Декларативные по императивному прежнему правила. Избегайте говорить о пользовательском интерфейсе; фраза путешествие с точки зрения того, что достигается на каждом этапе.
Если вы можете это сделать, вы можете повторно использовать свои шаги из своих небольших сценариев. Поместите ваши поездки клиентов (иногда называемые «тесты на дым») в отдельное место, даже если они выполняются в одной и той же части сборки. Запустите их все сначала, пока вам не понадобится больше (месяц или около того из этого нарушения заставит команду исправить первопричину, проблемы с окружающей средой и т. Д.!).
Будьте конкретным. Это не просто «пользователь»; это Сью, девушка по дороге, которая использует ваши полигоны на своей карте, чтобы попытаться обнаружить Покемонов, которых она еще не поймала. Конкретные истории действительно захватывают воображение людей и делают поездки незабываемыми. Сделайте разные поездки подходящими для разных лиц, если сможете.
Часто «то» одного сценария формирует «заданный» другого с другим аспектом поведения. Если вы соединяете их вместе, не беспокойтесь о «потом». Вам не нужно проверять результат, если вы собираетесь использовать его на следующем шаге. Например, если в меню должен отображаться определенный выбор, не проверяйте выбор; просто используйте его и предположите, что он есть. Проверки пользовательского интерфейса могут быть дорогими, и с этими более длительными поездками мы должны находиться в месте, где они обычно проходят. Если это не так, довольно просто добавить недостающие шаги в течение периода, в котором мы разрабатываем, почему они сломаны. Обычно это интеграционные тесты больше всего; проверка того, что определенные службы подключены и т. д., до запуска более длинного сценария.
Если ваше обычное путешествие клиентов включает пользователей, которые запутываются, совершают неправильные действия или иным образом тратят свое время, измените свой интерфейс. Опыт пользователя Опыт по-прежнему действительно, действительно важно и на самом деле не является частью BDD, так как трудно найти конкретные примеры для «легкого» или «прощающего» по сравнению с сравнениями и предложениями для пользовательского интерфейса. BDD - не серебряная пуля.
Очень распространено, что артефакты из разговоров вокруг полных поездок клиентов записываются или даже распространяются по всей стене офиса.Автоматические версии, однако, обычно создаются после, более мелкие сценарии завершены и функциональность работает.
Как правило, происходит дублирование между полными сквозными поездками клиентов и меньшими сценариями, которые охватывают аспекты поведения, такие как краевые случаи. Постоянные поездки обеспечивают быструю обратную связь и гарантируют, что время не тратится впустую; меньшие сценарии предоставляют документацию о том, как должна себя вести система. Дублирование в этом случае в порядке.
Если вы решили, что вы хотите, чтобы это полный путь, вот та вещь, которую я ожидал увидеть (и все, что я делаю здесь, является «декларативной против императива» вещью):
Given Sue's registered to catch Pokemons
And Bulbasaurs, Koffings and Pikachus were caught in Trafalgar square this year
When she filters for Pokemons caught between January and July
And adds a filter for "Poison" traits
And filters for "Bulbasaur"
When she searches for Pokemons
Then she should be asked to select an area of the map
When she selects an area around Trafalgar Square
Then she should be shown the Bulbasaur density
But not the Pikachu or Koffing density.
Используйте конкретные примеры. Намного легче понять и увидеть недостатки вышеизложенного или мое понимание Pokemon Go (которое я еще не играл), когда на самом деле в нем есть реальные идеи. Это что-то общее между этими поездками и меньшими сценариями.
Вы также увидите, что существует много «когда», и все они питаются друг другом. Если бы мы обсуждали отдельные аспекты поведения, каждый из них был бы предваряем «данный», в котором излагается контекст того, что было раньше, и результат, который позволил бы следующему «когда» быть «тогда». В этом случае мы собираем их вместе. Непрерывные последовательности «когда» очень распространены и полностью соответствуют этим видам путешествий, если вы считаете, что это , а не, глядя на один аспект поведения и не предоставляя его примеры (так что это не BDD). «Тогда» в середине пути появляется, когда результат является важной частью путешествия, в частности, обеспечивая неспецифическое руководство, на которое пользователь должен реагировать конкретно.
Не автоматизируйте эти с непониманием на месте! Автоматизированные поездки клиентов представляют собой значительные инвестиции (хотя их довольно легко собрать, если у вас есть более мелкие сценарии, покрывающие ту же функциональность). Сначала получите функциональность и покажите ее соответствующим заинтересованным сторонам. Вы не хотите вкладывать значительные средства в вещи, которые могут измениться с учебой и обратной связью.
Надеюсь, что это полезно, и спасибо за то, что заставляют меня думать об этом!
Я прошел через ваши ссылки и, к моему удивлению, я действительно узнал, что вы фактически использовали BDD в качестве инструмента тестирования. Это своего рода конфликт с тем, что вы сказали здесь. Почему вы думаете, что есть множество инструментов тестирования, которые конвертируют BDD в тесты, если они никогда не должны были быть инструментом тестирования? –
Реализация сценария в некоторых аспектах представляет собой реализацию теста. Но обычно это не реализация, где все детали упоминаются в сценарии. Важные аспекты, которые должны быть проверены, но не интересны для заинтересованных сторон бизнеса, скрыты в определениях шагов. В приведенном выше примере приведено множество подробностей, которые будут считаться само собой разумеющимися. Конечно, пользователь аутентифицирован, иначе было бы невозможно создать диаграмму. –
Убедитесь, что вы слушаете подкаст, на который я ссылаюсь в http://www.thinkcode.se/blog/2016/06/22/cucumber-antipatterns Это даст вам больше информации о том, почему вы предлагаете способ использования Огурец и BDD, к которому это не предназначено. –