Comments 21
Спасибо за статью! Лучики вам счастья!
А почему не на русском, cucumber прекрасно с ним работает, вот пример:
Функционал: Сложение чисел
Чтобы не складывать в уме
Все, у кого с этим туго
Хотят автоматическое сложение целых чисел
Сценарий: Сложение двух целых чисел
Допустим я ввожу число 50
И затем ввожу число 70
Если я нажимаю "+"
То результатом должно быть число 120
Вот еще немного примеров
Не знаю как вам, а мне очень нравится :)
Функционал: Сложение чисел
Чтобы не складывать в уме
Все, у кого с этим туго
Хотят автоматическое сложение целых чисел
Сценарий: Сложение двух целых чисел
Допустим я ввожу число 50
И затем ввожу число 70
Если я нажимаю "+"
То результатом должно быть число 120
Вот еще немного примеров
Не знаю как вам, а мне очень нравится :)
Круто, самое то для заказчика!
Не знаю как вам, а мне очень нравится :)
Тут вопрос даже не в том — нравится или нет. А в том — на каком языке вся остальная документация по проекту. Вообще важно писать сценарии приемочного тестирования на том же языке, что и вся остальная документация, так как таким образом не происходит расхождения в терминологии. Терминологические войны в проекте — та еще головная боль.
Интересная вещь.
Есть аналоги для других языков?
Есть аналоги для других языков?
Да, причем файл настроек не большой.
С русским есть только одна проблема — интеграция со свойствами других проектов (плагинов и модулей) коих в своем великое множество — получается каша. Ну и еще по умолчанию некоторыми пакетами многие поступки уже прописываются на английском.
С русским есть только одна проблема — интеграция со свойствами других проектов (плагинов и модулей) коих в своем великое множество — получается каша. Ну и еще по умолчанию некоторыми пакетами многие поступки уже прописываются на английском.
Если вы о языках програмирования, то Cucumber умеет работать с Java (Jruby).
Так же ближайшим временем выйдет аналог под python, дайте только допилю до нормального состояния:).
Так же ближайшим временем выйдет аналог под python, дайте только допилю до нормального состояния:).
Я подумал, что речь о Binary decision diagrams пойдёт :)
Интересно, расскажи где они применяются и с чем едят.
Основная идея — использование преимуществ табличного подхода, не спотыкаясь о его недостатки. Т.е. повышение скорости (которая теперь линейно зависит от количества переменных) вычисления функции при небольшом размере структуры данных.
Применяться могут везде, где нам необходимо быстро получить результат для небыстрой функции с небольшой областью применения (для примеров из википедии, состоящей из 2 элементов, а по сути вспомним, что у нас везде биты — мы ведь можем выразить функцию как набор булевых функций, например). Также BDD обладают свойством уникальности — для данной функции при данном порядке переменных существует единственный ROBDD. Поэтому может применяться для формальной верификации, проверки на эквивалентность.
Мне в этой структуре нравятся три вещи
1. Идея реализовать булеву функцию в виде графа, ускоряя вычисления.
2. Возможность производить вычисления не распаковывая BDD.
3. Уникальность.
И не нравится, что нахождение оптимального порядка переменных — NP полная задача (O(N!) кажется).
К сожалению, это оффтопик, поэтому здесь остановлюсь.
И спасибо за статью!
Применяться могут везде, где нам необходимо быстро получить результат для небыстрой функции с небольшой областью применения (для примеров из википедии, состоящей из 2 элементов, а по сути вспомним, что у нас везде биты — мы ведь можем выразить функцию как набор булевых функций, например). Также BDD обладают свойством уникальности — для данной функции при данном порядке переменных существует единственный ROBDD. Поэтому может применяться для формальной верификации, проверки на эквивалентность.
Мне в этой структуре нравятся три вещи
1. Идея реализовать булеву функцию в виде графа, ускоряя вычисления.
2. Возможность производить вычисления не распаковывая BDD.
3. Уникальность.
И не нравится, что нахождение оптимального порядка переменных — NP полная задача (O(N!) кажется).
К сожалению, это оффтопик, поэтому здесь остановлюсь.
И спасибо за статью!
Очень интересно! Продолжайте пожалуйста!
в целом весьма неплохо, но:
я, конечно, не гуру бдд, но перевод «step definition» как «описание поступков» сомнителен. я бы перевел как «описание шагов» либо «реализация шагов».
еще. пример не очень удачен. по крайней мере в том виде в котором он есть — работать не будет. по многим причинам. начиная с того, что article — локальная переменная, заканчивая тем, что контроллер не дергается, а соответственно response будет nil. и вообще, описание шага Then I should see «something» идет вместе в webrat'ом.
и еще. если уж речь идет о конкретном инструменте, неплохо для начала дать описание как настроить environment с cucumber'ом (хоть под рельсами, хоть без них), дать описание структуры директорий.
да, я зануда. извините.
я, конечно, не гуру бдд, но перевод «step definition» как «описание поступков» сомнителен. я бы перевел как «описание шагов» либо «реализация шагов».
еще. пример не очень удачен. по крайней мере в том виде в котором он есть — работать не будет. по многим причинам. начиная с того, что article — локальная переменная, заканчивая тем, что контроллер не дергается, а соответственно response будет nil. и вообще, описание шага Then I should see «something» идет вместе в webrat'ом.
и еще. если уж речь идет о конкретном инструменте, неплохо для начала дать описание как настроить environment с cucumber'ом (хоть под рельсами, хоть без них), дать описание структуры директорий.
да, я зануда. извините.
Вы правы.
Дело в том, что цель статьи ознакомить с методикой и только. Хотя приведенные выше тесты в рамках cucumber-а рабочие — проверено. Что касается нюансов реализации поступков, то они описаны так умышленно, для упрощения понимания, опять таки работы самого cucumber-а.
Насчет «шагов» и «поступков» вы также правы. Но мне больше нравится слово «поступки», так как «шаги» часто употребляется с иными контекстом и может ввести в заблуждение. Слово шаги также подразумевает некоторую этапность, которая в случае с (step definition) отсутствует.
Насчет environment — как уже говорил, приведенные настройки кукумбера работают и так, остальное уже выходит за рамки данной статьи.
Согласен, нужно освятить этот вопрос более подробно, но для этого необходимо также ввести публику и shoulda, и в webrat, также желательно ознакомить factory_girl и mocha, иначе не будет понятно где мы говорим о BDD и огурце, а где применяем другие инструменты.
Предлагаю разделиться и написать нам статьи по этим темам. А в конце заключительную статью, в которой полностью рассмотрим разработку реального приложения с помощью этих инструментов.
Что выбираете?
Дело в том, что цель статьи ознакомить с методикой и только. Хотя приведенные выше тесты в рамках cucumber-а рабочие — проверено. Что касается нюансов реализации поступков, то они описаны так умышленно, для упрощения понимания, опять таки работы самого cucumber-а.
Насчет «шагов» и «поступков» вы также правы. Но мне больше нравится слово «поступки», так как «шаги» часто употребляется с иными контекстом и может ввести в заблуждение. Слово шаги также подразумевает некоторую этапность, которая в случае с (step definition) отсутствует.
Насчет environment — как уже говорил, приведенные настройки кукумбера работают и так, остальное уже выходит за рамки данной статьи.
Согласен, нужно освятить этот вопрос более подробно, но для этого необходимо также ввести публику и shoulda, и в webrat, также желательно ознакомить factory_girl и mocha, иначе не будет понятно где мы говорим о BDD и огурце, а где применяем другие инструменты.
Предлагаю разделиться и написать нам статьи по этим темам. А в конце заключительную статью, в которой полностью рассмотрим разработку реального приложения с помощью этих инструментов.
Что выбираете?
Отличная тематика, если у вас есть, что рассказать, продолжайте, не останавливайтесь на этом!
Все конечно замечательно, спасибо и все такое, но… чем эта статья отличается от тупо перевода скринкаста, указанного в конце статьи? Там еще и подробнее все описано, и понятнее, и… работает!
Для BDD это список свойств (фич), который уместно писать вместе с заказчиком.
Уже набило оскомину утверждение, с заказчиком можно/нужно писать сценарии на Gherkin-е. С заказчиком нельзя написать полноценные сценарии тестирования. Заказчик — это такой зверь, которому нужно подавать решение его проблемы в самом вкусном и удобовоспринимаемом виде. Иначе не будет переварено.
Да даже, если речь идет о том, что вы при заказчике пишете сценарии, сами конвертируя в них его требования, то это не будет оценено по достоинству. Заказчику нужна картинка.
Это может быть, например, презентация с набором диаграмм (например user story и job story), но никак не техническая спецификация, коей является Gherkin.
Единственный случай когда с заказчиком можно разрабатывать требования к продукту на Gherkin-е — это когда заказчиком является технарь, либо какой-то отдел вашей же компании (то есть в любом случае технарь).
В других же случаях Gherkin при работе с заказчиком пригодится лишь на этапе утверждения объема работы на разработку. Мол мы вам привели в формально изложенном виде то что будет нами сделано, вы утвердили, мы разрабатываем. И делать это нужно только когда все это было уже изложено в более удобоваримом виде.
В общем, хватит людей в заблуждение вводить. Тут явно должны быть какие то другие формулировки. (Никаких претензий к переводчику, так как в общем статья полезная)
Sign up to leave a comment.
BDD с помощью Cucumber