Это вы по какой причине так решили, простите?

Вы сами накрутили это себе))

Если я верно понимаю, I.amonPage гарантирует, что следующая строка теста будет выполнятся только после полного рендера страницы, нет?

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

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

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

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

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

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

WaitForText решает проблему. Т. е. мне нужно самому позаботится о проверке, загрузилась ли страница полностью? Какова тут best practice? Ждать заданного текста в подвале?

Для меня это как-то было неочевидно :) Я думал, браузер там сам рапортует, что "всё отрендерил и можете тестировать дальше!".

WaitForText решает проблему. Т. е. мне нужно самому позаботится о проверке, загрузилась ли страница полностью? Какова тут best practice? Ждать заданного текста в подвале?

мне кажется нужно дождаться отображения самым жестких jsок

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

мы живем в 2к17ом году, где готовность страницы как документа не очевидна. А каждый веб компонент готов тогда, когда сам посчитает нужным.

Best practice - это добавлять к элементам дополнительный класс .rendered, и в своих тестах ещё и проверять пефвоманс клиентской части

Ух ты, это где написано про такое?

эмм ну как бы waitForElement это и подразумевает

эмм ну как бы waitForElement это и подразумевает

подразумевает что? можно почитать про добавление классов .rendered и т.д. и что это best practice. Как вообще функциональное тестирование предполагает как бест практис под собой еще тестирование производительности.

Я говорил только о данной команде, а не про всю автоматизацю

А можно все-таки пруфы. Человек сейчас пойдет городить везде кастомные приписки. а всего-то нужно было использовать неявное ожидание + правильный EC (Expected Condition)

(facepalm) Ещё раз говорю, насчёт времени ожидания из перфоманс метрик и доп. класса я говорил в контексте команды waitForElement. Я не говорю, что нужно "везде городить кастомные приписки" точно как же как и не говорю, что не нужно использовать неявное ожидание.

кто-нибудь понял, что написано выше?

объясните мне пожалуйста.

Поясните мне всё же логику происходящего: CodeceptJS написан почти что для домохозяек. Там вроде бы в логику зашито последовательное выполнение тестовых заданий: зашёл на URL, тут же начинаю проверять элементы, заполнять формы и т. д. Я в документах не видел конструкций вида, "а проверь-ка сначала, есть ли нужный тебе элемент, и только потом с ним взаимодействуй". Это я был невнимателен или авторам было это "и так понятно" и они просто не писали это как само-собой разумеющееся?

мы живем в 2к17ом году, где готовность страницы как документа не очевидна. А каждый веб компонент готов тогда, когда сам посчитает нужным.

this

Думаю вряд ли авторы документации станут писать за вас тесты.

http://codecept.io/acceptance/#smartwait

Спасибо. Я это видел, только интерпретировал по-другому. Типа это нужно использовать только когда идёт какой-то интерактив - пользователь тычет, окошки появляются. В общем, я понял - теперь прежде чем взаимодействовать с любым элементом, первой строчкой должен быть wait этого элемента.

подскажите где посмотреть рекомендации W3C или еще кого авторитетного по времени загрузки страницы?

есть ли какие-то метрики для анализа что такое быстрая загрузка/медленная загрузка страницы. Тулзы типа YSlow, Google Page speed, Консоль показывают аналитику, но метрики удачного/неудачного перфоманса непонятно какие применять

Спасибо. Я это видел, только интерпретировал по-другому. Типа это нужно использовать только когда идёт какой-то интерактив - пользователь тычет, окошки появляются. В общем, я понял - теперь прежде чем взаимодействовать с любым элементом, первой строчкой должен быть wait этого элемента.

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

Не зависимо от того, связано ли это с действиями пользователя (пользователь кликает, окошки открываются) или с рендерингом страницы, или ещё с чем-либо.

Всем большое спасибо - основную мысль я понял. Дальше - детали. Кстати, вот по теме правильных и неправильных wait'ов статья: https://habrahabr.ru/company/ruvds/blog/338984/

Ну, какой-то финальный вариант в конце статьи выглядит откровенно убогим.

Но чего не сделаешь ради того, что бы вкорячить промиси в свои тесты.

Можно, имхо, посмотреть как в протракторе реализован smartWait и на этом успокоиться.

В статье есть фраза "Помните о том, что текущая версия Selenium для JavaScript самостоятельно управляет промисами. Поэтому каждое выражение будет полностью завершено до перехода к следующему выражению. " Либо я его неверно истолковываю, но я также руководствовался - к следующей строке тест не перейдёт, пока полностью не выполнит предыдущую, т. е. в моём случае - пока страница не загрузится полностью, даже не рыпаться чего-то там делать или искать.

И авторы CodeceptJS вон чего пишут: "Tests are written in synchronous way. Test scenarios should be linear, so tests by themselves should not include promises or callbacks as well. However, behind the scene all actions are wrapped in promises inside the I object. Global promise chain is initialized before each test and all I.* calls will be appended to it as well as setup and teardown."

И здесь пишут, что я вроде как должен быть прав: "WebDriver будет дожидаться полной загрузки страницы (то есть момента, когда сработает событие “onload”), перед тем как вернуть управление обратно в ваш тестовый сценарий." https://selenium2.ru/docs/webdriver

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

А у меня нет. Рассмотрим пока простой случай.

Т.е.? вы не использовали неявно ожидание - у вас падал тест. Падал он потому что onload сообщал вебдрайверу - "иди дальше". код исполнялся дальше, не находил нужный элемент на странице и падал. вы заметили, что вставка ожидание "чинит" тест. Починился он потому, что селектор правильный, но он не был еще готов к этому моменту. onload() в современном мире jquery, ajax и SPA фрейморков ни разу не союзник вам, вот и все.

Большое спасибо за терпение! Последний вопрос и больше приставать не буду по этой теме :) Этот мой простенький тест то выполняется, то нет. Вот только что прям последовательно его запустил 10 раз. Половина раз OK, половина - "не вижу элемент"! Что, первый раз браузер быстренько успел сработать, поэтому элемент успел "увидеться", а второй раз рендеринг по какой-то причине замедлился (хотя не понятно по какой, процессор не загружен, всё кроме сайта локально на машине, а сам сайт в локальной сети) и без дополнительного wait элемент уже не "увиделся"?

Браузер рестартуется каждый раз.

Если CodeceptJS написан по аналогии с обычным Codeception, то там должно быть что-то вроде waitForElement/waitForElementVisible, которая будет ждать пока на странице не появится/отрендерится нужный элемент. Тут идёт ожидание не какого-то абстрактного времени, а именно конкретного элемента, что гораздо лучше. Перед каждым кликом на каждый элемент это, конечно, вставлять не стоит, но если точно известно, что после каких-то действий на странице может появится что-то новое, то стоит использовать

Для простых случаев , без всяких там ангуляров, и реактов, использование селенид фреймворка решает большинство проблем — методы типа click() уже за вас обернуты в ожидания. И на селениде тесты писать проще, чем на голом селениуме.

Ну, если интересно, то могу рассказать в личке субьективное мнение о бдд-инструментах и их полезности.

А чего в личку, я б послушала.

Я для себя решила,что bdd шикарная штука для автотестов, даже если вся разработка ведется не в bdd . Это дополнительный слой абстракции, который не только мне, как тестировщику, помогает писать тесты, но и любой человек видит адекватный отчет и может понять, что конкретно протестировано, какими шагами. А scenario outline кукумбера — удобнейшая вещь

Мне в бдд важнее всего наглядность покрытия функционала тестами. Есть фича — она покрыта такими и такими и сценариями. Тут даже pm может всунуться и сказать "о, а еще вот такой случай нам надо проверить". И мне очень важно то, что я могу отказаться от отдельно ведущихся тесткейсов (при должной ловкости) — все кейсы вести в фича файлах. Даже если они неавтоматизированны — в отчете по прогону будут шаги с пометкой "прогнать руками"

а мне на это фоне очень интересно, а как реализуется описание страниц приложения, когда еще нет приложения ? Вот написалы мы на bdd тест: Перейти на страницу авторизации Заполнить поля корректными данными и нажать кнопку "Отправить" Увидеть сообщение об успешной авторизации где-то должно быть описание веб-страницы/страницы приложения, что бы тестовое приложение осознало "куда конкретно тыкнуть" и "куда конкретно текст ввести" - но как написать, например, локаторы, пока страница не реализована? и еще момент: непонятно как решается проблема Наглядности покрытия (на мой взгляд, обычно, автоматизируется не все, а только бизносовые или смоут проверки) - или у вас автоматизируются Реально все кейсы которые генерирует тест-дизайн ? Как автоматизация не захлебывается поддержкой всего этого ?..

по первому пункту: у кукумбера в фича файле вы описываете сценарий - собственно то, что вы напечалали выше - это будут ваши шаги (given when then)? Затем в файле реализации прописываете методы для этих шагов. Можно помечать шаги Pending - это кукумбер будет понимать, что ваши шаги еще не покрыты тестовыми методами. Но даже если еще не реализована страница, вы сможете описать метод - например: this.When(/^ввожу логин"([^"]*)"$/, function (password: string) { loginField. setValue(password); return 'pending'; }). Затем в файле PageObject прописываете елемент loginField например: @selector(".login-field") public loginField: Element; когда вы получите реализацию - вам достаточно будет проставить/подменить локатор в вашем файле PageObject. ну или сказать разработчикам, а сделайте мне поле логина с классом "login-field"

Любое объяснение полезности бдд упирается на "придёт ПМ / человек с улицы и ему будет понятно " . Это какой бас фактор на проекте должен быть, чтобы тесты были проходным двором для случайных людей?)

Складывается ощущение, что yet another layer нужен для бизнеса, в котором нет доверия к языку программирования, сам код не может быть предельно понятен, тест рейл сьюты написаны на клингонском и только given when then обёртка автомагически делает хорошо

Ht,zn/

Коллеги.

Вы сейчас обсуждаете BDD с точки зрения TDD

почитайте про идею и философию BDD

Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.[2] Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.

Вы сейчас обсуждаете BDD с точки зрения TDD

При чем тут вообще тдд？

In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

И правда, при чем?

И правда, причем？

Речь выше о работе тестировщиков и функциональных тестов. Надеюсь мне не надо тебе рассказывать, что тдд не про это？

Нет, не надо, разумеется.

Просто посмотри саму оценку и суждения.

Я смотрел, люди обсуждают использование бдд инструментов в рамках процесса тестирования (а не написания кода). Это беседа про инструменты, а не про философии подходов, никак к тестированию не относящихся.

Всем привет. Посоветуйте для Java какой нить тестовый фреймворк, или что то в этом роде. Ситуация такая: у нас есть АПИ, который можно тестить только пошагово (найти такси, заказать найденный такси) и прочее. Так же с возможностью просматривать отчет на каком этапе оно сломалось

Всем привет. Посоветуйте для Java какой нить тестовый фреймворк, или что то в этом роде. Ситуация такая: у нас есть АПИ, который можно тестить только пошагово (найти такси, заказать найденный такси) и прочее. Так же с возможностью просматривать отчет на каком этапе оно сломалось

rest assured

Знает кто чат с автотестами на java?

rest assured

это либа для работы с rest api. У нас своя либа используется для работы с апи. Получается теперь хотим прогонять тесты по заданному workflow и потом результат показывать на телевизоре

вы спрашиваете нас, как вам получить результаты от вашей написанной либы?

заверните все в junit или testNG

А чего в личку, я б послушала.

Если интересно, то всегда можно ломануться в личку следом, расскажу\форвардну.

Он есть.

ссылку в студию)

ссылку в студию)

+

плз

кстати да, тоже интересно было бы

Он есть.

господа просят ссылочку)

пазязя

Там пока категорически мало контента, что бы это имело смысл куда-то шарить. Плюс меня Ричард за рекламу забанит.

Желающие ссылочек лучше могут наспамить мне в личку, что им там было бы интересно почитать. Как раз думаю на праздниках доберусь до саблайма и накатаю туда пару текстов. (В замен могу инвайтнуть :D)

Меня нет во флуде.

Так что нет, нельзя. :)

у нас появился флуд, где флуда мало и он вроде как имеет Code of Conduct, в отличии от предыдущей флудилки

Ничосе.

у нас появился флуд, где флуда мало и он вроде как имеет Code of Conduct, в отличии от предыдущей флудилки

это разве можно назвать флудом?)

Попозже будет, пока что здравый смысл и уважение к участникам.

это коллективное-сознательное. Просто вести себя, как хочешь, чтобы себя вели по отношению к тебе :)

я так понял в java тестовые фреймворки есть только testng и junit?