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

When I change something in my profile - тоже самое, можно писать но объем контекста становится гораздо больше

если говорить с точки зрения БДД, то оно более верно, но все это "можно написать" - время

А в ответ про пхпюнит, конечно можно и на пхпюните, но в том то и дело, что Бихат дает прозрачность, и в миксе с проверками ответов АПИ можно описывать проверки более сложной логики в гораздо более наглядном виде, абстрагируя код теста от описания логического флоу. Т.к кейс с АПИ профиля был дан не для того, что б показать как надо тестировать АПИ, а как достать ентити менеджер.

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

далеко не на каждый кейс

и в целом "I am <user>" это вполне себе реюзабельный стэп

тебе не важны email и пароль в сценарии, у тебя будет всеравно табличка что "юзер с такой-то ролью это вот такой-то юзер"

Сергей, я перкрасно понимаю что не каждый и когда надо тоже использую конструкции вида, Given I am logged as admin и тп

в данном конкретном случае важно

псмотри просто внимательно сценарий

1 степ:

Given follow email users: | email | plainPassword| firstname | lastname | | user@test.com | 1234567 | FirstName | LastName |

т.е есть упоминание какой емейл и какой пароль

второй же степ

Given I am successfully logged in with email: "user@test.com" and password: "1234567"

я понимаю о чем ты, но как по мне этот сценарий слишком сильно детализирован.

т.е этот же емейл и пароль

Given Bob registered and I logged in as Bob

вжух

т.е в наглядности зависимостей он более прозрачен чем

если у тебя добавится скажем день рождения в профиль - не надо будет переделывать сценарии

т.е в наглядности зависимостей он более прозрачен чем

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

если для себя - спроса нет

делай как тебе удобно)

цели - изолировать данные

цели - изолировать данные

сценарии для изоляции данных?

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

кто читает эти сценарии?

Given follow email users: | email | plainPassword| firstname | lastname | | user@test.com | 1234567 | FirstName | LastName | | user2@test.com | 1234567 | FirstName2 | LastName2 |

как минимум ты читаешь, через пол года, год

и не надо лезть смотреть кто там такой Боб, а кто не Боб )

что ты будешь делать если у тебя будет увеличиваться набор обязательных данных?

опять же универсальныйх случаев не бывает

так это и есть что нет универсального

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

Слишком много данных - фикстуры

ну и еще - если эти сценарии читают только программисты - я не вижу смысла в behat, это сложнее чем phpunit к примеру

Но там где можно смоделировать данные, имхо прозрачности это дает больше

еще есть нюансы - разделение фича контекстов, если у тебя он один на все сценарии - тогда твое желание понятно

конечно не один ))

я б сказал десятки в крупных проектах

я не вижу тут прозрачности - вот честно.... но это опять же мое ИМХО и я допускаю что тебе и твоей команде так удобно)

а по поводу контекстов, кто то писал про то что он привращается в ад, тут как раз и надо делить на отдельные контексты + в дополнение если это не АПИ, то и Page паттерн что б абстрогировать контекст от разметок страницы

тесты это тот же код, и там нужно следовать тем же правилам о разделении ответственности и т.д.

так что это логично)

да согласен, что каждому свой подход удобен и спорить какой лучше смысла нет

для меня основная ценность behat в том, что бы иметь возможность с точки зрения пользователя понять как что работает

и я не вижу смысла его юзать если у тебя хотя бы QA не прикладывают руку к описанию сценариев и их не читают продукт оунеры например

а продукт оунерам не очень интересно читать таблички "данных" или куда ты там json отправляешь

да, согласен и даже если его читают программисты, то листание листингов пхпюнита гораздо запутание, чем чтение бихат фич, вместо доки

да, согласен и даже если его читают программисты, то листание листингов пхпюнита гораздо запутание, чем чтение бихат фич, вместо доки

не соглашусь)

да и если у тебя и так есть нормальная дока по API - к чему такие муки испытывать?)

да оставь АПИ

пример АПИ это опять же только показать пример менеджера )

на АПИ то бихат не останавливается

я про сценарии вида I send json to....

я свои сценарии от UI отвязываю

что бы один и тот же сценарий можно было на любом уровне потестить

более того один и тот же сценарий может тестится девами к примеру на уровни АПИ, а QA на уровне работы с ЮИ

более того один и тот же сценарий может тестится девами к примеру на уровни АПИ, а QA на уровне работы с ЮИ

именно так

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

http://symfony.com/doc/current/testing.html - вот это в сф 4 вообще актуально?

к примеру, смотрю код класса Сlient, а там вообще нет метода request

хотя смотрю демо, там все как в примере. Что-то у меня не так, видимо

ERROR: S client not available

компонент BrowserKit не был установлен, вот что было не так.

Пофиксил SoC, сделал коммит)

когда инжектим em в метод public function action(EntityManagerInterface $em) {} - как его можно подменить в тестах?

когда инжектим em в метод public function action(EntityManagerInterface $em) {} - как его можно подменить в тестах?

вызвать метод с нужным?)

просто метод вызываю по урлу

а, вижу $parameters у $client->request()

ммм не

эту штуку разруливает argument resolver-ы

а потому тебе не надо в тестах явно указать - тебе надо в конфигурации DI для интерфейса свою имплементацию подсунуть

но вообще - в тестах API (или что ты там тестишь) подменять инстанс em тебе не нужно

смотрю сф4 демо, там сделано без подмены вообще - $blogPost = $client->getContainer()->get('doctrine')->getRepository(Post::class)->find(1);

у меня такой подход не сработал, не находит репозиторий - The class 'App\Repository\ContractRepository' was not found in the chain configured namespaces App\Entity

сработал, я вместо сущности пихал репозиторий.

смотрю сф4 демо, там сделано без подмены вообще - $blogPost = $client->getContainer()->get('doctrine')->getRepository(Post::class)->find(1);

это ж по сути end-to-end тесты, там не надо ничего подменять по хорошему

черный ящик

https://github.com/symfony/recipes/tree/master/php-http в чем разница кто вкуривает?

это что такое?

https://github.com/symfony/recipes/tree/master/php-http в чем разница кто вкуривает?

В чём разница между уткой?

ребята, в context сериализатора как-то можно передать какой name_converter использовать?

или настраивается только глобально через framework->serializer->name_converter не нашел в доках что туда кроме groups и object_to_populate можно еще настроить

Как я понял - туда можно вообще что угодно передавать и оно просто будет передано в нормалайзеры

А через OptionsResolver можно задать, чтоб для конкретного какая-то фигня была обязательной

В чём разница между уткой?

Уткой?

это что такое?

Пакеты для симфони 4

Как я понял - туда можно вообще что угодно передавать и оно просто будет передано в нормалайзеры

спасиб

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

кэши чистил, phpunit переустанавливал. На рабочем проекте проверил - те же зависимости и все ок

@fes0r @Enleur Знаете в чем разница между этими рецепотами https://github.com/symfony/recipes/tree/master/php-http ?

https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d

один - конкретный, второй - объединение 3-х