нет, ведь больше никде описывать не нужно

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

ну вот в бехате создаётся тикет(почините деление на ноль), который несёт чисто планировочный характер

потом с доменными экспертами составляются сценарии

который необходимо оттестировать

(на геркине например)

они и несут основную ценность

они и закладываются в behat

у вас вместе багтрекера лезут в код добавлять тест?

бля, не понял твоё предложение

вся бизнес ценность приложения сосредоточена в сценариях

который написаны на ubiquitous language

и говорят чё приложение умеет

для небольших приложений может и сойдет

как раз-таки нет

это именно для гигантских приложений

это как централизованная база знаний

ок. сценарий: я продавец, загружаю каталог своих продуктов. когда захожу на общий поиск для покупателей, должен их увидеть

ок

я программист

и разрабатываю приложения

приятно познакомитсья :)

ок. сценарий: я продавец, загружаю каталог своих продуктов. когда захожу на общий поиск для покупателей, должен их увидеть

м, crud простой, надо проверить, что в списке то, что нужно? Мы behat юзаем для покрытия доменной модели

с этим и postgresql справится

в плане с крудом

теперь реализация: чувак загружает xml файл в зипе на фтп, мы его проверяем на наличие malware, переливаем на другой сервер, там другое приложение его процессит и складывает в базу результаты. результаты получать нужно из базы + запрашивать данные с апи этого продавца. все результаты процессятся параллельно демонами на пхп. т.е задействовано 3 приложения(веб морда, процессинг демоны и демоны для поиска)

что за техническая хуита?)

где тут сложный домен

это ж типа деталь реализации

может по фтп зип файл, а может по ресту json

разницы не много

стоят перед доменом пара middleware, ну пускай

ну вот я описал бизнес кейс, который пришел от кастомера. и конкретная техническая реализация

как ты в behat это опишешь и реализуешь?

я это не буду описывать на бехат

эм

бехать для логики

а не для технической фигни

ок

что в твоем понимании логика?

правила доменной области

продавец может загружать товары не более 10 кг

3 раза в день

если у него нет заодлженности

блаблабла

behat не тестирует реализацию

обычно пишутся сценарии до кода

ну, смотря реализацию чего конечно

в соответствии с bdd

ты пишешь кейс в 3 предложения, а тебе для этого нужно сделать 100500 моков, поднять несколько баз и тд

не нужно

чтобы проверить

нет

я буду общаться с внешним интерфейсом приложения

например

через rest api

в случае бихата ты вообще будешь сущности подымать

а данные очищать после тестов кто будет?

да какая разница

и что если упадут сервисы?

китаец

которого я найму

я буду очищать

мда

если упадут сервисы

то у тебя не работает приложение

тадам

ERROR: S client not available

есть другие типы тестов

@Enleur в случае бихата зип там архив или нет, еще что-то не важно, важна сущность предметов. Как выше Юра писал только 10кг 3 раза в день летом с 9 до 17. И эти условия вообще не зависят от того, через что пришлось пройти данным к нашей бизнес-модели.

там вообще базы нет

а что они тогда проверяют?

rest интерфейс дергают?

нет

$basket = new Basket; $basket->addItem(SomeItem::withSomeProps()); $basket->addItem(SomeOtherItem::withCount(150)); ... и в итоге должен быть, например exception, что нельзя так много item'ов брать

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

абсолютно все равно сделали запрос по http, cli, ftp

в этом случае да, но такой логики это 5% приложения от силы

тогда у тебя не сложное доменное приложение

нанимай 10 китайцев

и это ты описал обычные юнит тесты, с которыми phpunit вполне успешно справляется

и иди отдыхать

в этом случае да, но такой логики это 5% приложения от силы

зависит от приложения

и это ты описал обычные юнит тесты, с которыми phpunit вполне успешно справляется

не юнит, в этом случае я не делаю никаких моков сущностей

работаю со всей доменной моделью

и они спокойно друг-друга дергают

и ещё много кого

только без сайд эффектов

:)

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

нууу, я бы так не сказал

вернее не классифицировал

ну, если надо как zapier, то да, но вот что-то типа слэка или жиры или гх, внешних интеграций миллион, но и внутряк серьезный(особенно в жире)

это у фаулера в книге описано..

ну например приложение для отслеживания посылок

своей логики мало, а интеграции нужно делать со всеми провайдерами

там будет много тестов на преобразование форматов

там да, юниты правят балом)

к каждому сервису свой специфический запрос нужен, и такой же ответ. это все юнит тестами покрывается и мокаются запросы/ответы от внешнего сервиса на изначально валидные, как по докам. определение какому провайдеру отправлять запрос, это нужно каждый номер разбирать - тоже юнит тесты при этом все тесты выполняются за секунду а если юзать функциональщину и тестировать все через сабмит формы каждый раз.. там 1 секунды не хватит

к каждому сервису свой специфический запрос нужен, и такой же ответ. это все юнит тестами покрывается и мокаются запросы/ответы от внешнего сервиса на изначально валидные, как по докам. определение какому провайдеру отправлять запрос, это нужно каждый номер разбирать - тоже юнит тесты при этом все тесты выполняются за секунду а если юзать функциональщину и тестировать все через сабмит формы каждый раз.. там 1 секунды не хватит

подожди, ты когда говоришь сервис это имеешь ввиду какой-то микросервис все в себе?