Я всегда считал, что Cucumber — это просто еще один инструмент в наборе инструментов тестирования моего разработчика. Как и RSpec, Test :: Unit или MiniTest :: Spec, я думал о Cucumber как о еще одном способе тестирования своего кода: я бы использовал RSpec для своих модульных тестов и Cucumber для своих интеграционных тестов. В то время как бизнес-ориентированный язык сценариев Cucumber показался мне забавным и инновационным, я никогда не задумывался над тем, почему тесты Cucumber были написаны таким многословным, сложным способом.
Затем на прошлой неделе у меня была возможность поговорить с Мэттом Уинном , соавтором книги «Огурец»: разработка , основанная на поведении, для тестировщиков и разработчиков , а также руководителем и инструктором по разработке , основанной на поведении (BDD). В длинном и увлекательном разговоре Мэтт объяснил мне основные идеи BDD и почему Cucumber был разработан именно таким, каким он был. Как вы увидите, Мэтт помог мне переосмыслить то, как я использую Cucumber во всех своих проектах. Вот основные моменты нашего разговора … возможно, прочитав это, вы начнете пересматривать то, как вы используете огурец!
Новости
Мэтт Винн
В: Прежде чем мы начнем, есть ли какие-то новости, о которых мы должны знать в мире огурца?
Большое объявление в мире Cucumber состоит в том, что Cucumber JVM была выпущена как 1.0 пару дней назад. Aslak действительно настаивал на том, чтобы это сделать: это порт Cucumber для запуска на Java VM как нативный код Java на протяжении всего пути.
В: Значит ли это, что Java-разработчики могут использовать Cucumber так же легко, как и Ruby-разработчики сейчас?
Они всегда были в состоянии, но это было что-то вроде уловки, которая вовлекала использование JRuby. Одна из умных вещей, которые Аслак сделал некоторое время назад, заключается в том, что он извлек библиотеку под названием Gherkin , которая является основной библиотекой синтаксического анализа файлов объектов. Он использует Ragel для разбора этих файлов. Ragel является генератором кода, поэтому он генерирует код, который анализирует файлы компонентов в Ruby, C, Java и JavaScript. Затем Java-код может быть портирован на C #; Вот как например работает SpecFlow . SpecFlow — это .NET-порт Cucumber, построенный на основе того же базового кода, что и Ruby Cucumber. Эта версия JVM также использует это.
история
Q: Как вы впервые познакомились с Cucumber?
Я посетил конференцию Software Practice Advancement в 2008 году в Кембридже, Великобритания. Вероятно, это была первая конференция, на которой я когда-либо был, и я был действительно напуган. Там были такие люди, как Майкл Фезерс ; Я только что прочитал его книгу. Дэн Норт тоже был там. Дэн и Джо Уолнс выступили с докладом « Удивительное приемочное тестирование» . Это было все о тех приемочных тестах, которые они писали — я думаю, что они оба работали в ThoughtWorks в то время и говорили об использовании примеров и попытке написать свои приемочные тесты так, чтобы они были действительно, действительно читабельными, чтобы вы могли мог бы поделиться ими с нетехническими людьми в команде. И это глубоко меня поразило, потому что я долгое время осознавал, что в программных проектах так больно было то, что, вы знаете, вы не можете получить эту связь с деловыми людьми.
Тем вечером я напился в баре с Дэном и Крисом Мэттсом, и моя BDD идеологическая обработка была завершена!
Q: У вас есть идея, где «Огурец» получил свое название? Я слышал легенду о том, как жена Аслака готовила с огурцами? Это правда?
Она собиралась укусить бутерброд с огурцом — это история, которую я слышал. Вы должны спросить их об этом.
Q: Мы можем распространить еще один слух; возможно, появится настоящая история.
Как огурец был предназначен для использования
В: Мне очень понравилось читать «Книгу огурцов» . После прочтения я пришел к выводу, что, вероятно, я не использую огурец, как я должен быть.
Что вы имеете в виду?
Q: Хорошо, я думаю, что мои шаги, мои особенности и сценарии написаны не очень хорошо. Я пишу их так, как я написал бы код на Ruby. Я не думаю о предполагаемой аудитории сценариев.
Сейчас я много работаю, обучая и тренируя людей, которые используют Cucumber, поэтому я вижу много команд, которые используют его плохо. Я стараюсь собрать всю команду в одной комнате, от владельца продукта до менеджера проекта, тестировщика, бизнес-аналитика и разработчиков. Я собираю всех в комнате и помогаю им прийти к общему мнению о том, как они хотят, чтобы их функции читались. Потому что все дело в том, что эти вещи работают хорошо, когда сценарии с Cucumber становятся той единственной точкой правды для всей команды.
Это становится чем-то таким, что каждый в команде чувствует, как он. Так что не только то, что пишут разработчики — это то, что заставляет браузер вспыхивать вокруг того, что делают разработчики. Если бизнес-аналитик задается вопросом о том, что система делает в этом конкретном случае, он может пойти и поискать функции и посмотреть. Они доверяют тому, что говорят функции.
Q: Так вы рассматриваете Cucumber как инструмент парного или группового программирования?
На самом деле я рассматриваю это как средство общения или совместной работы. Таким образом, играя в игру, вынуждая себя попытаться описать то, что вы хотите, чтобы программное обеспечение делало вместе, то, что вы в конечном итоге делаете, это всплывает все, что вы еще не поняли, и все то, что вы не делаете действительно уверен в. Это то, что Дэн Норт называет преднамеренным открытием.
Если я помещу команду в комнату и скажу: «Хорошо, хорошо, расскажите мне о своих пользовательских историях. Правильно. Расскажите мне о критериях приемлемости для этой пользовательской истории. Правильно. Давайте вместе запишем сценарий, который описывает, как кто-то может использовать эту функциональность ». И у них есть большой, большой аргумент! Вот что происходит. У них у всех немного разные способы описания, немного разные слова, которые они хотят использовать. И этот аргумент действительно, действительно важен, потому что он раскрывает все разные ментальные модели, которые есть у разных людей в команде. Выявив эти различия и вытащив их наружу, вы можете начать устранять разрыв между различными ментальными моделями людей. Чем раньше вы сделаете это в проекте, тем плавнее все будет.
Q: Это то, что вы имели в виду в книге «Вездесущий язык»?
Ну, вездесущий язык является ключевой частью построения этих мостов, да. Этот термин на самом деле взят из книги Эрика Эванса « Проектирование на основе предметной области: борьба со сложностями в основе программного обеспечения» . Это отличная книга о TDD и возникающей архитектуре — той архитектуре, которая появляется в гибком проекте, где вы продолжаете рефакторинг по ходу работы. Вы продолжаете изучать дизайн по ходу дела. Это трудно читать во многих отношениях, но одна действительно простая для понимания концепция в этой книге — это понятие «вездесущий язык». Это такая простая идея: вы просто прилагаете целенаправленные усилия, чтобы убедиться, что все используют одни и те же слова для вещей внутри и вокруг вашего проекта, от деловых людей до администратора базы данных.
Q: … потому что они могут не быть — или даже хуже, они могут использовать одни и те же слова для разных вещей?
Да, это еще хуже, не так ли, когда термин перегружен? Если разные люди используют разные слова для обозначения одних и тех же вещей, то вы просто настраиваетесь на падение. Каждый случай — это возможность для недоразумения, и когда вы увеличиваете это количество разговоров, которые будут иметь место в течение проекта, это страшно.
В: По вашему мнению, получите ли вы большинство преимуществ, которые предоставляет BDD, если вы написали сценарии, но никогда не выполняли их? Если вы никогда не писали определения шагов?
Я бы сказал, что вы получите около половины выгоды. Вы не получите ничего хорошего из регрессии. У вас нет системы безопасности для рефакторинга будущих изменений, которые вы делаете, и будущие итерации могут нарушить существующую функциональность. И у вас нет сторонней разработки, определяющей, какие юнит-тесты и код вам нужно написать — вы упускаете все это. Но преимущества, которые у вас есть, в том, что вы понимаете, какого черта вы должны строить в первую очередь — я думаю, что это половина выгоды, я действительно это делаю.
Q: Я думаю, что делаю огромную ошибку, думая, что Cucumber — это просто еще один инструмент в моем наборе инструментов для тестирования. Я никогда не хотел бы беспокоить моих спонсоров или бизнес-аналитиков техническими подробностями.
Возможно, вы носите шляпу бизнес-аналитика, а также шляпу разработчика. Может случиться так, что клиент, на которого вы работаете, не заинтересован в количестве деталей, которые вы должны включить в эти спецификации Cucumber. Они довольно утомительно утомительны.
Q: Кто должен использовать огурец? Только разработчики? Или деловые люди тоже?
Это должно как-то коснуться почти всех в команде. На моих занятиях я собираюсь продемонстрировать полную реализацию одного сценария перед всеми в команде, просто чтобы они знали, что такое части головоломки: что такое определение шага, какой сценарий есть и так далее. Но люди, которые запускают Cucumber из командной строки, обычно будут либо вашей сборкой Jenkins, либо разработчиками.
В: Но важно ли привлекать всю команду? По крайней мере, чтобы определить, каковы сценарии?
Всегда есть напряжение между вашими подонками, которые являются хорошими тестами и хорошей документацией. Представьте, что сценарии разнообразны: с одной стороны, деловым людям очень легко читать, отличная документация, но, возможно, не очень хорошие тесты. А на другом конце спектра — действительно хорошие тщательные тесты, но если вы покажете их владельцу продукта, они скажут: «Что это? Я совсем этого не понимаю ». Каждый раз, когда разработчик прикасается к ним, он, вероятно, притягивает их к техническому концу спектра и делает их немного менее доступными и читаемыми для нетехнических людей в команде. , Изо дня в день, как правило, разработчики обращаются к функциям, потому что они имеют доступ к git. Таким образом, вы должны продолжать прилагать целенаправленные усилия, чтобы заставить их работать как документация.
Гранулярность сценариев огурца
Q: Насколько гранулярными должны быть ваши сценарии с огурцом? На каком уровне детализации вы должны их писать? Я думаю, если бы они были более высокого уровня и абстрактными, то, скорее всего, вы могли бы привлечь клиентов и деловых людей.
Да. И я считаю, что они более полезны во многих отношениях. Одна вещь заключается в том, что они не привязаны к конкретной реализации. Поэтому, если вам действительно необходимо изменить взаимодействие с пользователем, путь, который должен пройти пользователь для достижения цели, вы, вероятно, говорите об изменении одного метода Ruby на своем уровне поддержки. Также они будут более читабельными для нетехнических людей.
Это тоже масштаб. В начале проекта, когда у вас есть только несколько функций, вы можете чувствовать себя комфортно, разговаривая на довольно низком уровне абстракции — щелкая мышью и т. Д. Когда вы начинаете увеличивать масштаб, когда у вас есть сотни или тысячи сценариев, вы перестаете иметь возможность читать вещи с низким уровнем детализации.
Одна из других вещей, которая происходит, когда вы используете больше императивного стиля и говорите на более низком уровне абстракции с большим количеством деталей, — вы упускаете возможность давать имена вещам. Потому что, если то, что вы делаете каждый раз, когда вы регистрируете пользователя, это:
| I go to the home page | |
| And I follow «sign up» | |
| And I fill in username with «Matt» | |
| And I fill in password with… |
by Если вы забудете дать этому маленькому путешествию название «регистрация», то у вас не будет возможности получить ручку, которую вы затем сможете использовать в беседе, чтобы поговорить об этом аспекте вашей системы.
Q: Это увлекательно — я никогда не думал об этом таким образом.
Тестирование доменных объектов напрямую
Вопрос: В одном из примеров в вашей книге вы начали с запуска сценариев непосредственно для объектов модели, например «Банк». Это хорошая идея? Вы сделали это намеренно?
Да. Мы говорили о вездесущем языке ранее. Когда вы впервые запускаете проект и создаете модель предметной области, очень приятно, если вы видите взаимосвязь между языком, который вы использовали в сценарии, и тем, как это выражается в модели предметной области. Потому что вы должны увидеть те же слова.
Таким образом, [тестирование моделей предметной области непосредственно с помощью Cucumber] поможет вам убедиться, что вы строите модели предметной области с согласованной терминологией, причем не только с точки зрения существительных, но и глаголов. Делают ли операции, то, что вы делаете с этими моделями, они сопоставляются с именами методов, которые вы используете?
Даже если в качестве мысленного эксперимента вы сказали себе: «Могу ли я запустить этот сценарий только на модели предметной области?». Это поможет вам написать сценарий на уровне, не зависящем от конкретного решения. Так что в книге очень тщательно продумано, что я пишу сценарий и заставляю его пройти первый раз, просто чтобы перейти к модели предметной области. И затем я оборачиваю пользовательский интерфейс вокруг модели предметной области, но я никогда не возвращаюсь и не меняю сценарий. Сценарий в равной степени применим к реализации пользовательского интерфейса или только к модели предметной области.
В: Вы также опровергаете или опровергаете другое заблуждение, которое у меня было годами: Cucumber — инструмент тестирования пользовательского интерфейса.
Это инструмент приемочного тестирования. И да, в 90% случаев заинтересованные стороны заботятся о том, чтобы пользователь мог переключаться между пользовательским интерфейсом и что-то делать. Но на самом деле речь идет об отражении того, что код делает на языке, доступном для людей, которые не могут прочитать код. Обычно интересные фрагменты этого кода отсутствуют в пользовательском интерфейсе.
Некоторое время назад я говорил о развитии, ориентированном на ипотеку (MDD) — я говорил о том, как использование очень важных технических сценариев активно исключает тех людей, с которыми, как утверждают, Cucumber обращаются. Если вы используете очень технический стиль, то нетехнические люди прочитают их один раз и скажут: «О, это похоже на то, что мне никогда не придется читать», и тогда они никогда не будут вас беспокоить. Некоторым разработчикам это даже понравится.
Приправы
Q: Я заметил, что вы создали приложение под названием Relish — что это?
Есть один нетехнический человек, которого вы почти всегда имеете в команде, который действительно хотел бы иметь возможность читать особенности Огурец. Но проблема в том, что они, вероятно, не знают, как использовать Vi, Git и т. Д. На самом деле Github — довольно полезный интерфейс для таких людей, чтобы читать функции, но даже тогда это все еще довольно техническое чувство. То, что вы хотите сделать, это дать им возможность просматривать функции и использовать их в качестве справочной документации, точно так же, как они могли бы использовать свои старые документы спецификации Word.
Для этого и нужен Relish — в некотором смысле это просто прославленный форматер HTML для функций Cucumber. Но это становится немного больше, чем это. Весь каталог функций публикуется онлайн, как электронная книга, где каждая функция и сценарий получают свой собственный постоянный URL. По всем функциям есть поисковый индекс Solr / Lucene. Мы поддерживаем страницы уценки, а также файлы функций, чтобы добавить больше редакционного контента. Крайне легко искать вещи и находить сценарии, в которых упоминаются определенные концепции предметной области, поэтому легко ориентироваться и использовать их в качестве справочной документации. И они выглядят красиво! Удивительно, как много может повлиять на вовлечение нетехнических людей, когда они используют дружественную среду, такую как Relish, для взаимодействия с функциями.
Благодарность!
Q: Извините, Мэтт — я должен идти … должен вернуться к своей повседневной работе …
Нет проблем. Хорошего дня — хорошей пятницы!
Q: Точно так же …
Приятно пообщаться с вами. Приветствия.