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

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

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

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

особенно если тебе нужно замокать 10 сервисов чтобы все взлетело

или подменять траффик в 10 сервисах, без разницы

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

останется проверить, что совместоно это работает :) http://developerslife.ru//public/images/previews/201605/9f009fe5-c735-44df-95b9-b220854c067f.jpg

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

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

останется проверить, что совместоно это работает :) http://developerslife.ru//public/images/previews/201605/9f009fe5-c735-44df-95b9-b220854c067f.jpg

повторюсь - никто не отменяет проверку того, что всё это работает нормально. Просто то, что сделали - запускается без участия тестировщиков, для более раннего фидбека.

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

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

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

профит в том, что без этого релизы "всё вместе" тестились по 20 часов. И находили нерабочую кнопку покупки тесты, которые исполнялись по 3-4 часа, в виду специфики сервиса. а теперь замоканые фронтовые тесты запускаются на коммите, и дают фидбек в течении 5 минут релизные тесты сократились до тех же самых тестов, что замоканые, но уже без моков, в меньшем количестве

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

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

так точно

профит в том, что без этого релизы "всё вместе" тестились по 20 часов. И находили нерабочую кнопку покупки тесты, которые исполнялись по 3-4 часа, в виду специфики сервиса. а теперь замоканые фронтовые тесты запускаются на коммите, и дают фидбек в течении 5 минут релизные тесты сократились до тех же самых тестов, что замоканые, но уже без моков, в меньшем количестве

ну да, интересный кейс) а почему 3-4 часа?

сколько там тестов?)

сколько там тестов?)

500000, ты же знаешь ответ =)

одна покупка - 5 минут. Нужно около 75 покупок чтобы проверить все внешние сервисы. Плюс комбинации с разными входными данными :\ количество тестов считать неблагодарное занятие. 75 тестов исполняются 90% времени из 900+

5 минут на один тест, серьезно?

а почему именно так? там супердлинный сценарий?

Может быть процессинг долгий сам по себе.

а почему именно так? там супердлинный сценарий?

проверить поиск москва-питер - 40 секунд на 1 реквест ;)

только поиск, только 1 запрос

у вас бэк асинхронный? оО или он просто так долго реплаит?

выписка, бронь - еще минуты 2 на еще два запроса

а почему не вынести комбинации с разными данными на апи уровень?

а почему не вынести комбинации с разными данными на апи уровень?

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

у вас бэк асинхронный? оО или он просто так долго реплаит?

просто много поставщиков данных + огромный технический долг ;)

ясно-понятно))

соболезную

почему? ;) отличный простор для помощи разработке. То, что требуется от QA

а я думал у меня тесты медленные)

соболезную тех. долгу

не задачам, так-то они звучат интересно

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

всё сваливают на "бизнесс приоритеты" и тем самым, мол мы тут не причём, это всё бизнесс

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

надо пытаться это бороть

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

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

и как успехи? пока с этим долгом стало удобнее жить

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

и как успехи? пока с этим долгом стало удобнее жить

ну мы каждый спринт выделяем время на тех. долг) иначе можно зарасти в говне

ну мы каждый спринт выделяем время на тех. долг) иначе можно зарасти в говне

да не, я у него спрашиваю. С нашими тех долгами всё понятно =)

а, сорян)

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

а с тех долгом? пока это выглядит "мы научились жить с техдолгом".

а с тех долгом? пока это выглядит "мы научились жить с техдолгом".

тогда перефразирую. Наличие техдолга понижает testability. Это бизнесу я продаю под ускорением процессов тестирования и более быстрой поставкой фич

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

ну так вы "понижение testability" исправляете за счёт этих самых грязных хаков

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

не правда :( не понимаю, где грязные хаки в том, чтобы отрепортить фронтендеру о проблеме заранее исключив влияние бекенда, и наоборот.. > Насколько это помогает выпиливать техдолг, который мешает жить разработчики более спокойно рефакторят, имея инструмент который им оперативно сообщает о поломках (юниты не 100% покрывают еще)

время на рефактор выделяется в рамках задач "Добавить возможность тестировать то то то то"

теперь понятнее стало, спасибо

ну если запросы по 40 секунд бегают то тут только мокать фронт совсем, это да))

не правда :( не понимаю, где грязные хаки в том, чтобы отрепортить фронтендеру о проблеме заранее исключив влияние бекенда, и наоборот.. > Насколько это помогает выпиливать техдолг, который мешает жить разработчики более спокойно рефакторят, имея инструмент который им оперативно сообщает о поломках (юниты не 100% покрывают еще)

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

либо поднимать копии бэкенда у себя локально

но если вы не все данные берете от себя то наверное это не очень возможно

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

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

либо поднимать копии бэкенда у себя локально

локально запустить не сложно, сложно поднять идентичную проду среду. Это задача текущего квартала ;)

"можно"

локально запустить не сложно, сложно поднять идентичную проду среду. Это задача текущего квартала ;)

докер в помощь

"можно"

сделано

докер в помощь

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

ERROR: S client not available

https://t.me/Blockchain_Developers

Котоны, я тут краем уха услышал что срок валидности сертификатика istqb 4 годика. Рили?

вроде пишут, что нет: ISTQB certification will not expire like the CSTP certification

Вот я и задумался. Вроде бессрочен)

Народ в PageObject верхняя менюшка сайта является частью страницы или же это часть лейаута? Куда пихать логику по взаимодейсвтию с этим меню?

а она часть каждой страницы или нет?

Это сложный вопрос

пихай куда удобнее, в чем вообще вопрос)

А куда удобнее?)

куда тебе удобнее и как работать проще будет туда и пихай, нет?)

тебе паттерны или тестить?)

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

Т.е. для удобства

Мне удобнее вообще не писать тесты а фигачить лапшекод и сразу в продакшен

Мне удобнее вообще не писать тесты а фигачить лапшекод и сразу в продакшен

ну и так можно))

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

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

Можно сделать дополнительную страничку, от которой наследовать те, на которых она есть, а те на которых её нет - от base page или иной её реинкарнации

А как насчет trait/mixin ?

Так ведь оно одинаково будет работать на всех подстраницах

Ну да менюшка то одна и та же

Или это не про контракты, а-ля implements

Так и зачем описывать эти методы в каждой странице заново?)

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

Это даже лучше наследования имхо

Вот чёт не уверен, но можно попробовать Как минимум ты в каждой странице будешь указывать его.

Зато можно разные трейты подключать

FooterTrait, IndexFooterTrait и т.д.

Смотрите про пейдж обджект на ютьбах страны