а в селениуме плохо все, медленно, кнопку поменял на ссылку или какой-другой компонент и он упал, id поменял и он упал, кнопку убрал сделал по enter и он упал

короче

сплошная боль)

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

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

нл без них никак, если у тебя космолет

нл без них никак, если у тебя космолет

обычно говорят про 10%-20% интеграционных, это далеко не всегда через UI

далекоооо не всегда

ну да, репозиторий на выборки потестить

угу

обычно говорят про 10%-20% интеграционных, это далеко не всегда через UI

ну так я про функциональные/приемочные

проще интеграционный вставить

а не про интеграционные

ну так я про функциональные/приемочные

ты не ответил на вопрос - как вы следите за тем что приемочные тесты не ушли в рассинхрон со спецификацией/требованиями?

а что такое функциональный?

ты не ответил на вопрос - как вы следите за тем что приемочные тесты не ушли в рассинхрон со спецификацией/требованиями?

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

а не про интеграционные

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

автоматизаторы пишут тесты по этим тесткейсам (щас ручники учатся сами писать тесты)

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

почему бы не взять behat?)

и писать сценарии и примеры поведения системы

сложна

ну в плане

заодно спеку получите0

реально ж сложна

реально ж сложна

ну да, надо учиться)

будет там I send http request to "/asdasd/asda/sdasd/"

будет там I send http request to "/asdasd/asda/sdasd/"

ну так я ж про нормальные

ну очень сложно дойти до того, как это надо делать

мне и сейчас сложно

When I exchange 10 something to another currency Then I should receive 1 yet another currency as gift

ну очень сложно дойти до того, как это надо делать

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

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

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

да, это я знаю)

иногда выходит очень сложно

что аж теряет смысл

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

пытаешься что-то назвать проще

спрашиваешь че как

но вот бывает упираешься сильно)

короче, я уверен, что behat/cucumber это очень сложный инструмент

но если вы его осилили, то прям профита много

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

просрут все полимеры

и зачем тогда все это(

ну да, потому в аутсорсе я пока боюсь его юзать

а бехат он чего, селениумом рулить умеет?

у меня было за 2 года только 2 проекта где бехат помог бы

так да, поэтому мне в продукте легко

а бехат он чего, селениумом рулить умеет?

не только

а бехат он чего, селениумом рулить умеет?

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

хоть phpunit, хоть peridot, хоть behat)

селениуму никакая)

но вообще mink

http://mink.behat.org/en/latest/

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

не понял какая разница?)

это ж тестраннер

посмотрел по-диагонали quick introduction — похоже на паттерн page object, только для бизнес процессов типа. наверное тогда можно сказать, что у нас переизобретен свой собственный маленький бехат с пейджобджектами и адовыми билдерами?

в основе behat - gherkin

это важная шляпа

одна из ключевых

за gherkin стоит знание вашего dsl

и отражение его в доменной моделе

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

можно шаги из шагов собирать просто вызывая методы других шагов

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

на человеко-понятном языке

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

ERROR: S client not available

о.о

зеленые юниттесты и не обещают работу приложения

никакие зеленые тесты не обещают

угу

даже полный набор всего чего только можно с 146% покрытия может сказать "скорее всего все ок"

зеленые юниттесты и не обещают работу приложения

не нужно путать unit тестирование и приемочное тестирование

не путаю

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

ну ок, если все покрывать только смоуками и приложение не огромное, то относительно быстро, но мы ж про серьезные вещи говорим

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

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

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

https://www.youtube.com/watch?v=5civ2BYQ600

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

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

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

мир меняется, требования меняются - ничего не поделаешь ;)

это я знаю, когда мы говорим функциональные — имеем в виду приемочные :)

unit тесты хорошо живут в случае тестирования библиотеки которая будет повторно использоваться - НО есть проблема - 80% времени мы пишем бизнеслогику

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

unit тесты хорошо живут в случае тестирования библиотеки которая будет повторно использоваться - НО есть проблема - 80% времени мы пишем бизнеслогику

ну собсна для этого они и преднозначены. мня смутило что юниты переписываются.

такое бывает, просто у меня есть опыт работы с 10 летней кодовой базой.

unit тесты хорошо живут в случае тестирования библиотеки которая будет повторно использоваться - НО есть проблема - 80% времени мы пишем бизнеслогику

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

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

чаще они либо дополняются либо удаляются за неактуальностью

разве приемочные не отличаются от функциональных??

функциональные так или иначе цепляют детали реализации

а приемочные - это ж чисто "сейчас я на странице товаров. когда ввожу в форму поиска имя товара XYZ, затем я вижу отфильтрованный по имени XYZ список товаров."

поправьте, если ошибаюсь

там тонкая грань на самом деле )

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

про значения там понятно, а вот именно ключи с сохранением структуры

там тонкая грань на самом деле )

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

ну и в написании и применении