Почему же нет? Телефон при съёмке может быть направлен под определенным углом к поверхности земли, и от этого фото должны зависеть (например земля по ногами или верхушки деревьев). А вот температуру модели обычно degrees не называют
Я поискал по нашим статьям и, пожалуй, специальных материалов на эти темы у нас нет, но касаемо этих вопросов ответы такие: - Делаем E2E тестов атомарными и быстрыми. В этом случае тесты, разумеется, уже не будут E2E, правильнее теперь их называть UI-тестами. Атомарность могут обеспечить всего 2 вещи: дизайн тест кейсов и ускоренная подготовка данных. Например, вместо E2E сценария, где пользователь обычным образом регистрируется, логинится и начинает работать с веб-приложением, тест кейс должен предполагать минимальное число действий, чтобы получить нужный результат. Для этого кроме сокращения числа необязательных и длительных степов, мы еще и по максимуму стараемся перенести их на сторону API. Стандартных инструментов здесь, как правило, недостаточно, поэтому на бэкенде бывает нужно написать дополнительные тестове эндпоинты, которые помогут создать ускоренную регистрацию, логин, и подготовку аккаунта. Это самые затратные шаги. Идеально, если после логина сразу же произойдет редирект в нужную вью с подготовленным для теста состоянием. Тогда оставшаяся UI часть теста представляет из себя пару кликов и проверку, в нашем случае эта часть длится 2-3 секунды для подавляющего числа тестов. - Про демо-страницы так подробно рассказать не смогу, т.к. я сам не фронтендер, но мы используем архитектуру микро-фронтендов, которая уже стала де-факто стандартом в индустрии, по этому запросу гуглится огромное количество статей. Далее на демо-странице должно быть замокано все взаимодействие с внешней частью страницы, дополнительно могут быть добавлены переключатели состояния элементов страницы, т.к. в реальности они определяются именно внешними элементами. Очень удобно, когда эти параметры являются параметрами URL, тогда можно просто по ссылке получить нужное состояние страницы.
Надеюсь, ответил :) Если у вас остались более специфичные вопросы - милости прошу в ЛС
Отличный вопрос! Дело в том, что наши UI-тесты очень далеки от Е2Е тестов, они атомарны и очень быстры, для каждого теста все подготовки данных делаются через API-запросы, а средняя длина сценария после логина и загрузки страницы составляет 1-3 секунды. Кроме того, мы стараемся по минимуму работать с полноценным веб-приложением, большинство тестов работают с облегченными демо-страницами или плейбуками.
Для того, чтобы билд с упавшими тестами ушел в продакшен, каждый упавший тест должен быть проверен ответственными, но в нашем случае это суммарно несколько десятков тестов в день перед каждым деплоем, что не такая большая проблема.
Насчет отключения тестов действительно, может звучать опасно, но здесь стоит определить, насколько тест должен быть нестабильным, чтобы было очевидно, что вреда он приносит больше, чем пользы. Иначе каждый работающий с тестом человек в компании будет разбираться с уже известной проблемой.
Что касается 100 стабильных билдов и затем внезапные падения - тоже хороший вопрос. Для этого у нас есть отдельный маленький сервис, который работает в билдах для мерджа в RC (там ожидается, что ветки проверены и багов уже быть не должно). Если тест с хорошей статистикой внезапно сломался и упал во всех сборках несколько раз подряд, ответственные сразу получают нотификацию.
Мой вопрос возник именно отсюда. Со статьями согласен, процент не очень хороших статей достаточно велик, и модерация часто страдает. Но для себя я заметил, что намного лучше осваиваю материал, если смотрю видео на ютубе где все те же мысли из книг наглядно анимированы. По паттереам пытался читать знаменитую банду четырех, и ничего скучнее в жизни своей не видел (не значит, что книга плохая, это абсолютно субьективно, head first еще более-менее). Причем есть куча источников, где те же самые паттерны объяснены намного более наглядно и с отличными примерами, и все это не книги. И после этого довольно странно было бы на собесе получить минус карандашиком за то, что "не читаю книг".
Очень странно и скомкано выглядит последний пункт про книги. Хотелось бы подробностей, почему вы считаете, что книги это лучший из возможных форматов получения знаний? Чем хуже курсы, статьи или видео?
В аналитике речь не об "угадываниях", а о вероятностях. У нас есть статистика, которая показывает определенную тенденцию, выводы из этого можно сделать разные. И гарантий, разумеется, эти цифры не дают.
В заголовке про Россию ничего и не сказано. Кроме того, в России и не было массовых сокращений, наоборот - нехватка специалистов и соответствующий рост зарплат.
Курсы порой стоят слишком дорого и оценить их качество практически невозможно. Имхо намного лучший вариант - разбираться самому, в работе именно этот навык пригодится и никогда не устареет. А если хочется быстрее выучиться, то проще и дешевле найти себе ментора и общаться с ним только на нужные тебе темы.
До использования Allure Test Ops мы пользовались Allure Report, то есть привычка развешивать аннотации для степов и классов в компании уже была. Тем не менее, даже если бы пришлось внедрять систему сейчас, мы могли бы передавать в степ преобразованное имя java-метода, используя те же листенеры, эту же логику мы сейчас используем, чтобы не приходилось вручную писать имя теста. А что касается самих листенеров, мы используем кое-какие из JUnit5 (там вместо листенеров экстеншены) или AspectJ (который идет вместе с Allure, и хоть это и не совсем листенер, но суть в контексте та же) для того, чтобы, например, автоматически прокидывать методы с @BeforeEach как самостоятельные степы.
как именно анализируете, насколько в этом помогает Allure TestOps?
Очень хороший вопрос и ответ на него тянет на отдельный пост, нюансов много :) Если попытаться рассказать коротко: Allure TestOps играет роль централизованного хранилища истории теста, из этой истории можно посчитать сколько раз за промежуток времени тест "прошел" или "упал". Поделив одно на другое, получаем некий коэффициент стабильности, и из общей картины определяем, какой коэффициент нас устраивает, а какой - нет.
не думали над генерацией тест-кейсов из таких же лейблов и прочей обёртки
Об этом в статье и шла речь, мы не храним тест-кейсы отдельно от автотестов, они могут существовать в кратком виде до того как появятся сами автотесты, а дальше все генерируется автоматически.
Почему же нет? Телефон при съёмке может быть направлен под определенным углом к поверхности земли, и от этого фото должны зависеть (например земля по ногами или верхушки деревьев). А вот температуру модели обычно degrees не называют
Я поискал по нашим статьям и, пожалуй, специальных материалов на эти темы у нас нет, но касаемо этих вопросов ответы такие:
- Делаем E2E тестов атомарными и быстрыми. В этом случае тесты, разумеется, уже не будут E2E, правильнее теперь их называть UI-тестами. Атомарность могут обеспечить всего 2 вещи: дизайн тест кейсов и ускоренная подготовка данных. Например, вместо E2E сценария, где пользователь обычным образом регистрируется, логинится и начинает работать с веб-приложением, тест кейс должен предполагать минимальное число действий, чтобы получить нужный результат. Для этого кроме сокращения числа необязательных и длительных степов, мы еще и по максимуму стараемся перенести их на сторону API. Стандартных инструментов здесь, как правило, недостаточно, поэтому на бэкенде бывает нужно написать дополнительные тестове эндпоинты, которые помогут создать ускоренную регистрацию, логин, и подготовку аккаунта. Это самые затратные шаги. Идеально, если после логина сразу же произойдет редирект в нужную вью с подготовленным для теста состоянием. Тогда оставшаяся UI часть теста представляет из себя пару кликов и проверку, в нашем случае эта часть длится 2-3 секунды для подавляющего числа тестов.
- Про демо-страницы так подробно рассказать не смогу, т.к. я сам не фронтендер, но мы используем архитектуру микро-фронтендов, которая уже стала де-факто стандартом в индустрии, по этому запросу гуглится огромное количество статей. Далее на демо-странице должно быть замокано все взаимодействие с внешней частью страницы, дополнительно могут быть добавлены переключатели состояния элементов страницы, т.к. в реальности они определяются именно внешними элементами. Очень удобно, когда эти параметры являются параметрами URL, тогда можно просто по ссылке получить нужное состояние страницы.
Надеюсь, ответил :) Если у вас остались более специфичные вопросы - милости прошу в ЛС
Отличный вопрос! Дело в том, что наши UI-тесты очень далеки от Е2Е тестов, они атомарны и очень быстры, для каждого теста все подготовки данных делаются через API-запросы, а средняя длина сценария после логина и загрузки страницы составляет 1-3 секунды. Кроме того, мы стараемся по минимуму работать с полноценным веб-приложением, большинство тестов работают с облегченными демо-страницами или плейбуками.
Для того, чтобы билд с упавшими тестами ушел в продакшен, каждый упавший тест должен быть проверен ответственными, но в нашем случае это суммарно несколько десятков тестов в день перед каждым деплоем, что не такая большая проблема.
Насчет отключения тестов действительно, может звучать опасно, но здесь стоит определить, насколько тест должен быть нестабильным, чтобы было очевидно, что вреда он приносит больше, чем пользы. Иначе каждый работающий с тестом человек в компании будет разбираться с уже известной проблемой.
Что касается 100 стабильных билдов и затем внезапные падения - тоже хороший вопрос. Для этого у нас есть отдельный маленький сервис, который работает в билдах для мерджа в RC (там ожидается, что ветки проверены и багов уже быть не должно). Если тест с хорошей статистикой внезапно сломался и упал во всех сборках несколько раз подряд, ответственные сразу получают нотификацию.
Много вы книг читали, где примеры на нескольких языках одновременно?
Мой вопрос возник именно отсюда. Со статьями согласен, процент не очень хороших статей достаточно велик, и модерация часто страдает. Но для себя я заметил, что намного лучше осваиваю материал, если смотрю видео на ютубе где все те же мысли из книг наглядно анимированы. По паттереам пытался читать знаменитую банду четырех, и ничего скучнее в жизни своей не видел (не значит, что книга плохая, это абсолютно субьективно, head first еще более-менее). Причем есть куча источников, где те же самые паттерны объяснены намного более наглядно и с отличными примерами, и все это не книги. И после этого довольно странно было бы на собесе получить минус карандашиком за то, что "не читаю книг".
Очень странно и скомкано выглядит последний пункт про книги. Хотелось бы подробностей, почему вы считаете, что книги это лучший из возможных форматов получения знаний? Чем хуже курсы, статьи или видео?
В аналитике речь не об "угадываниях", а о вероятностях. У нас есть статистика, которая показывает определенную тенденцию, выводы из этого можно сделать разные. И гарантий, разумеется, эти цифры не дают.
В заголовке про Россию ничего и не сказано. Кроме того, в России и не было массовых сокращений, наоборот - нехватка специалистов и соответствующий рост зарплат.
Забавно, что trick перевели как "способ", в итоге получаем 5 способов делать несвязные вещи.
Курсы порой стоят слишком дорого и оценить их качество практически невозможно. Имхо намного лучший вариант - разбираться самому, в работе именно этот навык пригодится и никогда не устареет. А если хочется быстрее выучиться, то проще и дешевле найти себе ментора и общаться с ним только на нужные тебе темы.
Ого, это что же получается, в IT не только шарить надо, так ещё и работать придется, а не только зарплату получать? Ну уж нет, тогда это не подходит
Минус карандашиком за кликбейт в названии, а в остальном спасибо за хорошую статью, слишком много популизации адекватности на собесах не бывает
До использования Allure Test Ops мы пользовались Allure Report, то есть привычка развешивать аннотации для степов и классов в компании уже была. Тем не менее, даже если бы пришлось внедрять систему сейчас, мы могли бы передавать в степ преобразованное имя java-метода, используя те же листенеры, эту же логику мы сейчас используем, чтобы не приходилось вручную писать имя теста. А что касается самих листенеров, мы используем кое-какие из JUnit5 (там вместо листенеров экстеншены) или AspectJ (который идет вместе с Allure, и хоть это и не совсем листенер, но суть в контексте та же) для того, чтобы, например, автоматически прокидывать методы с @BeforeEach как самостоятельные степы.
Очень хороший вопрос и ответ на него тянет на отдельный пост, нюансов много :) Если попытаться рассказать коротко: Allure TestOps играет роль централизованного хранилища истории теста, из этой истории можно посчитать сколько раз за промежуток времени тест "прошел" или "упал". Поделив одно на другое, получаем некий коэффициент стабильности, и из общей картины определяем, какой коэффициент нас устраивает, а какой - нет.
Об этом в статье и шла речь, мы не храним тест-кейсы отдельно от автотестов, они могут существовать в кратком виде до того как появятся сами автотесты, а дальше все генерируется автоматически.
Это стандартная фишка, работает и c Allure Report