Я начинал писать на TestNG в 2016м. Тогда был JUnit4, который не только уступал в функциональности, но и уже 2 года, к тому времени, не выпускал обновления. А сейчас они оба имеют аналогичные возможности, оба развиваются и стали лишь делом вкуса и привычки. Более того JUnit5 себя отлично зарекомендовал и теперь является тоже отличным выбором.
А, понял про что речь теперь. Да, вещь хорошая, но размер такого шага увеличится процентов на 20 из-за переносов и скобок. Читаемость в минимальное число экранов снизится, что влияет на быстрый анализ автотеста глазами. Для нас DataTable хороший и лаконичный формат, который себя хорошо зарекомендовал и исправно работает.
Стек для бэкенда у вас выбран отличный, сам такой бы выбрал, но заменил бы JUnit5 на TestNG. Более того движок серверных тестов у нас на этом же стеке, если снова посмотреть на текст статьи. Cucumber у нас лишь для того, чтобы написание автотестов было удобно вынести в браузер - через webIDE. Так получается, что сервер - это не единственная платформа, требующая автоматизации у нас, а есть еще 2 мобильные платформы и веб. Таким образом наш проект позволяет в едином пространстве писать 4 вида автотестов без всяких настроек. Если вы занимаетесь только автоматизацией бэкенда, то можно и обойтись фреймами, работающими только с кодом. Для этого я и написал финальную часть "Не повторяйте это дома, трюк выполнен подготовленными специалистами" - где я призываю все хорошенько обдумать, ведь моя статья не руководство к действию, а кейс.
Я встречал TOML только в инвентарниках Ansible. По мне не похоже ) По Docstring не понял, как его тут можно применить, но с удовольствием бы послушал ваши мысли по этому поводу, хоть у нас и Java, а не Python.
Вложенность у нас делается через точку, а списки так и остаются, так как у нас бывают редко:
Но если вы отправляете очень объемные рестовые запросы, то не стоит, как мне кажется, их засовывать в геркин полностью, а то это сильно ударит по читаемости автотестов. Советую использовать что-то типа FreeMarker'а для создания запросов-шаблонов, в которых большая часть значений будет статична(и только изменяемая часть станет тем самым DataTable), а ссылаться в самом шаге на шаблон по его названию *.json. Мы так сделали для мокирования, так как там нужно ставить заглушку на ответ, который почти всегда объемный.
Тут 2 параметра: эндпоинт и тип рестового метода. А в DataTable заполнение ключ-значение json. По-умолчанию все, кроме true/false, является типом String. Если нужно что-то другое, то можно воспользоваться в value допками, типа "Integer:". При запуске запрос виден полностью с урлом, хедерами и json в привычном виде:
Прошу понять, что я не топлю за геркин, это лишь средство достижения цели. А цель была именно дать возможность писать тесты главным людям, имеющим знания ожидаемого поведения всей системы. Тест-кейсы не всегда показывают всю глубину необходимых проверок, поэтому автоматизаторы или разработчики, которые пишут автотесты по ним, часто сужают проверку, нежели ручные тестировщики, тем самым снижая качество продукта. Плюс добавляется игра в сломанный телефон с аналитиками про то, а как должно было быть. Поэтому мы и выпилили автоматизаторов из процесса написания автотестов и дали им заниматься фреймом.
Мое мнение, что если вы хотите дать своим продуктовым разработчикам ещё и автотесты писать, то для этого должны быть максимальные условия с точки зрения документации, тест-кейсов и процессов. Плюс давать проверять тому же человеку, что и изобрел что-то — это антипаттерн тестирования. Ведь все мы, как известно, не видим в своем глазу бревна.
Раньше у нас был другой тип использования автоматизаторов — гибридный. Это когда люди находятся в продуктовых командах, пишут автотесты этой команды и еще тестируют руками новый функционал. У нас этот вариант совсем не взлетел, так как все ресурсы уходили на ручное тестирование, а автоматизация была по остаточному принципу. Потом с автоматизаторов сняли ручное тестирование, чтобы число автотестов увеличилось, но и это, в команде, работающей над быстрорастущим приложенем с редизайнами, давало КПД близкий к 0. Потом сели, подумали и сделали вот такой продукт, который уже отлично себя зарекомендовал.
Это я к тому, что, когда только внедрялся огурец, было совсем не до аккуратного выстраивания BDD. Поэтому это был булшит, который логировал методы и давал их чуть переиспользовать с выплывающем подсказом от cucumber. Не я внедрял, но зато работа с ним помогла допустить вариант с текущим решением.
Как же rest assured может быть никому не нужен, если все его используют для API-автотестов. Вот, например, можно взять https://mvnrepository.com/tags/rest — он там номер 1. Библиотека существует уже больше 7 лет с постоянными обновлениями и пишется в очень приятной флюентинтерфейсной манере — чистый кайф.
Выбор junit 5 и testng окончательно стал лишь вкусовщиной, так как они оба отличные фреймворки с идентичными возможностями. Мое личное предпочтение — TestNG.
По селениуму согласен, что есть Selenide и другие обертки, начинающиеся на Selen..., но для нас это лишь крошечный слой, не влияющий на скорость выполнения автотестов. Основной движок UI-автотестов у нас на Atlas.
Тема довольно холиварная, но я с вами соглашусь — разработчики имеют другую психологию, нежели АТ и ФТ. Моя же команда состоит из людей, которые автоматизаторы, выросшие из кузни качества продукта. Поэтому и не было проблем в глубинном понимании всех болей тестирования, чтобы получился ортодоксальный продукт, прежде всего для ФТ. Мы разработчики лишь с той точки зрения, что пишем нормальный код и на 80% занимаемся кором. В дополнение мы собираем постоянную обратную связь, чтобы слушать и слышать наших ключевых пользователей — ФТ. Люди же, находящиеся на позиции классических разработчиков и которым дали сделать продукт автоматизации, часто срезают углы не от хорошей жизни, а лишь потому, что с них не снимают в это время продуктовую разработку.
Так как в нашей компании специалисты всех направлений имеют возможность писать автотесты на нашем продукте, то ревью итога все равно остается за ФТ. Они отвечают за качество продукта и за то как он оттестирован. Поэтому ситуации, что кто-то накидал длинную макаронину, которая что-то много того и не того проверяет — невозможна. У нас каждый автотест проверяет 100% тест-кейса.
Я искренне надеюсь, что те менеджеры, которые говорят "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится" имеют достаточно опыта в нашей индустрии, чтобы принять это решение взвешенно.
Мы нескончаемо (как и все спецы качества в других компаниях) работаем над проработкой общей базы и артифактория по тестам. Понимание важности очень трудно показывать при смене классического метода подхода к структуре автоматизации — тут действительно были сложности, но сейчас уже есть все метрики, чтобы сказать, что такой подход для нас гораздо удачнее.
Работы над слоем BDD мы проделали в самом начале нашего пути переписывания кора. Сделали это основательно, чтобы не тратить на это время после. У нас теперь действительно все пишут и поддерживают. Это не умножение работы, а ее распределение, со снижением узкого горлышка AT и ФТ. Команда сама решает, кто будет писать автотесты в конкретный момент времени, а затем сама несет за них ответственность.
Ничего не преукрашивал, тут просто наш кейс с итогом, что взлетело. А BDD у нас идеально лег под вынос всех параметризированных шагов в webIDE и максимальному снижению планки входа в написание автотестов — без настроек и танцев с бубном.
Может, факт того, что наш ТТМ сократился на день за счет новых автотестов, убедит вас в том, что и с деливери у нас всё ок )
Ага, пишут достаточно активно. Поначалу было сложно вводить это в продуктовые команды из-за естественного сопротивления, но сейчас уже всё ок. Основные пользователи продукта автоматизации это аналитики и ручные тестировщики — те it-спецы, которые точно знают, как должно быть правильно на проверках. BDD-уровень мы не поддерживаем — там уже нами разработаны все необходимые виды шагов для воплощения любого существующего сценария. Мы пилим и улучшаем кор, а сами автотесты в руках команд.
Да, я раньше к cucumber'у тоже скептически относился. Но потом мы как раз использовали этот самый "лишний уровень" и все его преимущества для выноса на веб-платформу и написания там автотестов любым it-спецом. Все получилось и работает хорошо. Скорость написания и поддержки увеличились в разы.
Я начинал писать на TestNG в 2016м. Тогда был JUnit4, который не только уступал в функциональности, но и уже 2 года, к тому времени, не выпускал обновления. А сейчас они оба имеют аналогичные возможности, оба развиваются и стали лишь делом вкуса и привычки. Более того JUnit5 себя отлично зарекомендовал и теперь является тоже отличным выбором.
А, понял про что речь теперь. Да, вещь хорошая, но размер такого шага увеличится процентов на 20 из-за переносов и скобок. Читаемость в минимальное число экранов снизится, что влияет на быстрый анализ автотеста глазами. Для нас DataTable хороший и лаконичный формат, который себя хорошо зарекомендовал и исправно работает.
Стек для бэкенда у вас выбран отличный, сам такой бы выбрал, но заменил бы JUnit5 на TestNG. Более того движок серверных тестов у нас на этом же стеке, если снова посмотреть на текст статьи. Cucumber у нас лишь для того, чтобы написание автотестов было удобно вынести в браузер - через webIDE. Так получается, что сервер - это не единственная платформа, требующая автоматизации у нас, а есть еще 2 мобильные платформы и веб. Таким образом наш проект позволяет в едином пространстве писать 4 вида автотестов без всяких настроек. Если вы занимаетесь только автоматизацией бэкенда, то можно и обойтись фреймами, работающими только с кодом. Для этого я и написал финальную часть "Не повторяйте это дома, трюк выполнен подготовленными специалистами" - где я призываю все хорошенько обдумать, ведь моя статья не руководство к действию, а кейс.
Я встречал TOML только в инвентарниках Ansible. По мне не похоже )
По Docstring не понял, как его тут можно применить, но с удовольствием бы послушал ваши мысли по этому поводу, хоть у нас и Java, а не Python.
Вложенность у нас делается через точку, а списки так и остаются, так как у нас бывают редко:
Но если вы отправляете очень объемные рестовые запросы, то не стоит, как мне кажется, их засовывать в геркин полностью, а то это сильно ударит по читаемости автотестов. Советую использовать что-то типа FreeMarker'а для создания запросов-шаблонов, в которых большая часть значений будет статична(и только изменяемая часть станет тем самым DataTable), а ссылаться в самом шаге на шаблон по его названию *.json. Мы так сделали для мокирования, так как там нужно ставить заглушку на ответ, который почти всегда объемный.
Вот пример, как это сделано у нас:
Тут 2 параметра: эндпоинт и тип рестового метода. А в DataTable заполнение ключ-значение json. По-умолчанию все, кроме true/false, является типом String. Если нужно что-то другое, то можно воспользоваться в value допками, типа "Integer:". При запуске запрос виден полностью с урлом, хедерами и json в привычном виде:
Прошу понять, что я не топлю за геркин, это лишь средство достижения цели. А цель была именно дать возможность писать тесты главным людям, имеющим знания ожидаемого поведения всей системы. Тест-кейсы не всегда показывают всю глубину необходимых проверок, поэтому автоматизаторы или разработчики, которые пишут автотесты по ним, часто сужают проверку, нежели ручные тестировщики, тем самым снижая качество продукта. Плюс добавляется игра в сломанный телефон с аналитиками про то, а как должно было быть. Поэтому мы и выпилили автоматизаторов из процесса написания автотестов и дали им заниматься фреймом.
Мое мнение, что если вы хотите дать своим продуктовым разработчикам ещё и автотесты писать, то для этого должны быть максимальные условия с точки зрения документации, тест-кейсов и процессов. Плюс давать проверять тому же человеку, что и изобрел что-то — это антипаттерн тестирования. Ведь все мы, как известно, не видим в своем глазу бревна.
Раньше у нас был другой тип использования автоматизаторов — гибридный. Это когда люди находятся в продуктовых командах, пишут автотесты этой команды и еще тестируют руками новый функционал. У нас этот вариант совсем не взлетел, так как все ресурсы уходили на ручное тестирование, а автоматизация была по остаточному принципу. Потом с автоматизаторов сняли ручное тестирование, чтобы число автотестов увеличилось, но и это, в команде, работающей над быстрорастущим приложенем с редизайнами, давало КПД близкий к 0. Потом сели, подумали и сделали вот такой продукт, который уже отлично себя зарекомендовал.
Это я к тому, что, когда только внедрялся огурец, было совсем не до аккуратного выстраивания BDD. Поэтому это был булшит, который логировал методы и давал их чуть переиспользовать с выплывающем подсказом от cucumber. Не я внедрял, но зато работа с ним помогла допустить вариант с текущим решением.
Как же rest assured может быть никому не нужен, если все его используют для API-автотестов. Вот, например, можно взять https://mvnrepository.com/tags/rest — он там номер 1. Библиотека существует уже больше 7 лет с постоянными обновлениями и пишется в очень приятной флюентинтерфейсной манере — чистый кайф.
Выбор junit 5 и testng окончательно стал лишь вкусовщиной, так как они оба отличные фреймворки с идентичными возможностями. Мое личное предпочтение — TestNG.
По селениуму согласен, что есть Selenide и другие обертки, начинающиеся на Selen..., но для нас это лишь крошечный слой, не влияющий на скорость выполнения автотестов. Основной движок UI-автотестов у нас на Atlas.
Тема довольно холиварная, но я с вами соглашусь — разработчики имеют другую психологию, нежели АТ и ФТ. Моя же команда состоит из людей, которые автоматизаторы, выросшие из кузни качества продукта. Поэтому и не было проблем в глубинном понимании всех болей тестирования, чтобы получился ортодоксальный продукт, прежде всего для ФТ. Мы разработчики лишь с той точки зрения, что пишем нормальный код и на 80% занимаемся кором. В дополнение мы собираем постоянную обратную связь, чтобы слушать и слышать наших ключевых пользователей — ФТ. Люди же, находящиеся на позиции классических разработчиков и которым дали сделать продукт автоматизации, часто срезают углы не от хорошей жизни, а лишь потому, что с них не снимают в это время продуктовую разработку.
Так как в нашей компании специалисты всех направлений имеют возможность писать автотесты на нашем продукте, то ревью итога все равно остается за ФТ. Они отвечают за качество продукта и за то как он оттестирован. Поэтому ситуации, что кто-то накидал длинную макаронину, которая что-то много того и не того проверяет — невозможна. У нас каждый автотест проверяет 100% тест-кейса.
Я искренне надеюсь, что те менеджеры, которые говорят "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится" имеют достаточно опыта в нашей индустрии, чтобы принять это решение взвешенно.
Очень рад, что вам понравилась моя история :)
Мы нескончаемо (как и все спецы качества в других компаниях) работаем над проработкой общей базы и артифактория по тестам. Понимание важности очень трудно показывать при смене классического метода подхода к структуре автоматизации — тут действительно были сложности, но сейчас уже есть все метрики, чтобы сказать, что такой подход для нас гораздо удачнее.
Работы над слоем BDD мы проделали в самом начале нашего пути переписывания кора. Сделали это основательно, чтобы не тратить на это время после. У нас теперь действительно все пишут и поддерживают. Это не умножение работы, а ее распределение, со снижением узкого горлышка AT и ФТ. Команда сама решает, кто будет писать автотесты в конкретный момент времени, а затем сама несет за них ответственность.
Ничего не преукрашивал, тут просто наш кейс с итогом, что взлетело. А BDD у нас идеально лег под вынос всех параметризированных шагов в webIDE и максимальному снижению планки входа в написание автотестов — без настроек и танцев с бубном.
Может, факт того, что наш ТТМ сократился на день за счет новых автотестов, убедит вас в том, что и с деливери у нас всё ок )
Ага, пишут достаточно активно. Поначалу было сложно вводить это в продуктовые команды из-за естественного сопротивления, но сейчас уже всё ок. Основные пользователи продукта автоматизации это аналитики и ручные тестировщики — те it-спецы, которые точно знают, как должно быть правильно на проверках. BDD-уровень мы не поддерживаем — там уже нами разработаны все необходимые виды шагов для воплощения любого существующего сценария. Мы пилим и улучшаем кор, а сами автотесты в руках команд.
Да, я раньше к cucumber'у тоже скептически относился. Но потом мы как раз использовали этот самый "лишний уровень" и все его преимущества для выноса на веб-платформу и написания там автотестов любым it-спецом. Все получилось и работает хорошо. Скорость написания и поддержки увеличились в разы.