Я имел в виду как раз, что эта грань выражается в разнице между "Сейчас я на '/products'" и "Сейчас я на странице товаров"

behat например позволяет тебе писать для бизнес-пипл "я на странице товаров" а разработчики к этому биндят GET /products

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

но опять же, сложна)

за бизнес хотелки

разработчики пишут в 2 раза больше кода

который надо поддерживать и актуализировать

который надо поддерживать и актуализировать

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

Кузнецов php 5 на примерах Люк Веллинг разработка... Дэвид Скляр Рецепты программирования

что из этого пояитть стоит?)

там обычно pageobject используется

разработчики пишут в 2 раза больше кода

можно и в 10 раз больше кода писать, количество кода слабо коррелируется с трудозатратами.

и то что понаписали мэнеджеры

через page object работает со страницей

ну и плюс парсер небольшой

там обычно pageobject используется

это если ты всякие силениумы делаешь, а можно просто работать напрямую с сервисным слоем например. Зачем тебе UI дергать

ты же логику хочешь проверить

ок ок ок )

програмировать должны программировать

а UI... как я уже говорил, если делать UI на каком-нибудь angular2/react/ember то все UI компоненты полностью stateless и их можно легко и просто покрывать юнит тестами

програмировать должны программировать

и тесты писать тоже

ты предлагаешь ui тестить

в отвязки от бэкенда

ты предлагаешь ui тестить

да)

через bdd в частности behat ?

через bdd в частности behat ?

а UI это часть бизнес нидс?

тоесть мы берем react, angular берем behat

нет, UI будет покрыт юнит тестами

который вообще из другова стэка

тоесть мы берем react, angular берем behat

behat = приемочные тесты.

который вообще из другова стэка

есть cucumber.js если на то пошло)

но повторюсь

приемочные тесты ничего не знают про UI

а UI про приемочные тесты

ну так получается behat бесполезен (я не знаю людей кто на php frontend делает )

верней связки вроде smarty или twig

....

ты все перепутал)

возможно

я не против юнит тестов интерфейса)

ты behat-ом проверяешь бизнес логику, а не UI

так?

бизнес логику чего?

фронта или бэкенда?

...бизнеса?)

или вместе)

ммм.... системы в целом?)

ну да так логично

какой смысл ты вкладываешь в это ненужное разделение?)

обычно вся логика на бэкэнде

теперь мы берем человека (менджера) так как он понятия не имет

как программировать

и что такое Http поверх которого мы работаем

если она есть на клиенте - берем те же gherkin сценарии и натравливаем calabash/cucumber.js/cucumber + jruby

мы пишем ему костыли чтобы он писал бизнес терминами

а мы это под копотом реализовывали

мы пишем ему костыли чтобы он писал бизнес терминами

эм....

почему кастыли?

давай так

при этом парсем его бизнес херь, интерпретируем, переводим в код и выполняем

сразу условимся что в твоих сценариях на gherkin нет реюзабельных стэпов

не кажется что первые пункты нахер не нужны и можно сразу код писать

при этом парсем его бизнес херь, интерпретируем, переводим в код и выполняем

ты так говоришь буд-то бы это за нас не делает behat)

Кузнецов php 5 на примерах Люк Веллинг разработка... Дэвид Скляр Рецепты программирования

что из этого пояитть стоит?)

не кажется что первые пункты нахер не нужны и можно сразу код писать

А с чего ты взял, что понял задачу

Как понять, когда задача готова

не кажется что первые пункты нахер не нужны и можно сразу код писать

а теперь представь что клиент не знает чего он хочет. Точнее не все детали раскрыты. Он тебе дает пачку хотелок, ты по ним строишь примеры поведения в виде given when then. Только gherkin, кода еще нет.

ERROR: S client not available

bdd в отличие от tdd не требует теста вперед

bdd в отличие от tdd не требует теста вперед

bdd в отличии от tdd требует вперед наличие понимания того что ты делаешь и зачем

given, when, when это хорошо в плане общения с заказчиком

then*

а теперь представь что клиент не знает чего он хочет. Точнее не все детали раскрыты. Он тебе дает пачку хотелок, ты по ним строишь примеры поведения в виде given when then. Только gherkin, кода еще нет.

Представь, что клиент знает, чего он хочет :D

given, when, when это хорошо в плане общения с заказчиком

именно про это bdd как бы и есть)

разработчики пишут в 2 раза больше кода

это байки менеджеров. разработчики на 1 строчку попавшую в коммит делает 2 строки не попавших

Представь, что клиент знает, чего он хочет :D

чет слабо)

это байки менеджеров. разработчики на 1 строчку попавшую в коммит делает 2 строки не попавших

+1

ок

это нужно именно писать новый синтаксис и поддерживать его

это нужно именно писать новый синтаксис и поддерживать его

ты о чем вообще?

Уже сделали за тебя

все уже написано

gherkin же

Gherkin

given when then можно написать в jira

И реализовать довольно просто разработчику

given when then можно написать в jira

можно, называется это тогда specification by example

не создавая лишние абстракции

не создавая лишние абстракции

и не получая профита дополнительного

А можно в фича-фпйле

и не получая профита дополнительного

переиспользования кода?

переиспользования кода?

запомни - код никогда не реюзается. реюзаются только абстракции

ну и опять же - какое нафиг переиспользование кода?!)

ну я к тому что обычно это выглядит как набор pageobject (можно погуглить)

Goto позволяет код переиспользовать)

цель BDD - Behaviour Driven Development - устранить стоимость перевода требований от языка бизнес на язык понятный техникал пипл

далее поверх этих pageobject есть некий интерпретатор который дергает методы с нужными параметрами

ну я к тому что обычно это выглядит как набор pageobject (можно погуглить)

ну это не bdd, это просто чуваки юзают behat как тестовый фреймворк

ок

слишком высокие абстракции для меня