Comments 7
Таки у вас кто-то кроме разработчика реально так пишет?
Или всё равно разработчик добивает это до реально рабочего состояния?
Или всё равно разработчик добивает это до реально рабочего состояния?
В основном правила придумывают (на основе требований) и имплементируют только разработчики, но вместе с задачей иногда предоставляются и acceptance criteria в нотации Given-When-Then, а это уже полдела и остается только заимплементировать.
Ну таки да, в этом вся печаль. Основная идея BDD то в первую очередь в том что требования пишут те, кому они ближе, а на деле всё равно разработчики.
Но, в любом случае интересный опыт, спасибо =)
Но, в любом случае интересный опыт, спасибо =)
Я наверное не правильно понял Ваш изначальный вопрос, описанное в статье решение — это proof of concept, рабочего и пользуемого приложения нет. Но идея как раз в том, что модифицировать правила должен именно «заказчик», а программист только бы расширял словарь «фраз»
Крайне суровые аналитики, конечно, могут писать BDD-тесты, но ввиду их относительной редкости, BDD-тесты чаще пишут разработчики/тестировщики в зависимости от особенностей команды. А BDD-тесты выступают человеко-понятными acceptance criteria с одной стороны, и машино-читаемыми интерфейсами к внутренностям тестов с другой стороны. И тогда BDD-тесты могут закрыть вопроса: А как работает сейчас (работало вчера, будет работать завтра — относительно простым человеческим языком)? И если тест упал, то как происходит декомпозиция в непосредственно реализацию набора действий?
У нас реально тестировщики пишут сценари в BDD тестах (мы используем jBehaive).
А идея рулов на основе BDD сценариев интересная: человеческий язык всегда ближе. Вопрос только, как с теми же drools — производительность и надежность. BDD движки не расчитаны на производительную работу. Мы столкнулись с утечками памяти, проблемами в параллельной работе и т.п.
А идея рулов на основе BDD сценариев интересная: человеческий язык всегда ближе. Вопрос только, как с теми же drools — производительность и надежность. BDD движки не расчитаны на производительную работу. Мы столкнулись с утечками памяти, проблемами в параллельной работе и т.п.
Вы конечно же правы, надежность cucumber при использовании в продакшене вызывает вопросы. Но внушает надежду тот факт, что имплементация cucumber (я видел конечно же только java) в принципе не шибко сложная — один только подход к разбору feature диво простой, поэтому шансы поправить что-то самостоятельно высоки.
Sign up to leave a comment.
Использование cucumber в качестве движка бизнес правил