Добрый день, @old-door! Спасибо за статью, познавательно и очень кстати, как раз столкнулся с тестированием canvas. Пока проверяю данные в ответе бека, но обязательно применю твой подход.
Добрый день! Спасибо за дельные советы и замечания, приняли к сведению. По отдельным классам страниц и классам методов, скорее всего будет зависеть от проекта, на сколько он масштабный. Например, для не больших лэндинг-страниц, можно хранить и в одном классе и методы и локаторы. По докер файлам, спасибо, исправим. По таймаутам тоже скорее всего будет зависеть от проекта и от инфраструктуры тестового окружения, есть тяжеловесные проекты и вот там мы как раз выносим таймауты в переменные окружения, для удобного и быстрого их изменения.
Добрый день, Коллеги! Присоединюсь к данному комментарию:
Я не сторонник больших и длинных заголовков, заголовок должен быть информативным, плохая практика пытаться затащить шаги и условия. Для этого есть другие параметры баг-репорта.
Количество шагов в идеале должно стремится к 3. Лучше использовать состояния системы, описанных в пред условиях. Думаю предусловие как раз подходит к описанию того пользователя или учетной записи или роли, под которой мы должны воспроизводить дефект.
Правилом хорошего тона является указание ФР сразу после шагов, а затем ОР, т. к. мы ведем своими шагами читающего к сути самого дефекта или бага.
Мне очень понравились примеры из статьи, буду использовать, а понравились тем, что мы из примеров действительно поймем насколько кандидат будет глубоко копать, а это в скоупе зависит от набора компетенций, навыков, владения инструментами. И что самое главное, очень актуально в наши дни когда нужно уметь разбираться со многими технологиями с нуля.
Добрый день, если честно, то кроме того, что Playwright быстрее, производительнее и удобнее в использовании из этой статьи я и понял. Хотелось бы конечно более подробной информации, в плане использования протоколов взаимодействия с основными движками браузеров, да и WebKit это тот же Safari.
Добрый день, @old-door! Спасибо за статью, познавательно и очень кстати, как раз столкнулся с тестированием canvas. Пока проверяю данные в ответе бека, но обязательно применю твой подход.
Добрый день! Спасибо за дельные советы и замечания, приняли к сведению. По отдельным классам страниц и классам методов, скорее всего будет зависеть от проекта, на сколько он масштабный. Например, для не больших лэндинг-страниц, можно хранить и в одном классе и методы и локаторы. По докер файлам, спасибо, исправим. По таймаутам тоже скорее всего будет зависеть от проекта и от инфраструктуры тестового окружения, есть тяжеловесные проекты и вот там мы как раз выносим таймауты в переменные окружения, для удобного и быстрого их изменения.
Добрый день, Коллеги! Присоединюсь к данному комментарию:
Я не сторонник больших и длинных заголовков, заголовок должен быть информативным, плохая практика пытаться затащить шаги и условия. Для этого есть другие параметры баг-репорта.
Количество шагов в идеале должно стремится к 3. Лучше использовать состояния системы, описанных в пред условиях. Думаю предусловие как раз подходит к описанию того пользователя или учетной записи или роли, под которой мы должны воспроизводить дефект.
Правилом хорошего тона является указание ФР сразу после шагов, а затем ОР, т. к. мы ведем своими шагами читающего к сути самого дефекта или бага.
Мне очень понравились примеры из статьи, буду использовать, а понравились тем, что мы из примеров действительно поймем насколько кандидат будет глубоко копать, а это в скоупе зависит от набора компетенций, навыков, владения инструментами. И что самое главное, очень актуально в наши дни когда нужно уметь разбираться со многими технологиями с нуля.
Добрый день, если честно, то кроме того, что Playwright быстрее, производительнее и удобнее в использовании из этой статьи я и понял. Хотелось бы конечно более подробной информации, в плане использования протоколов взаимодействия с основными движками браузеров, да и WebKit это тот же Safari.