Смок-тестирование релиз-кандидата автотестами за 15 минут

[Wolonter]

Правильно «continuous integration».

А о чем статья? Вы написали тесты?

[Iksanova]

Статья об автоматизации смока. Да мы написали автотесты и успешно их используем.
Спасибо, что поправили.

[NeverIn]

Сколько же смоук тестов позволяют оценить готовность сборки?

[Iksanova]

На момент написания статьи на нашем проекте их было 149, количество их меняется при увеличения/уменьшения основного функционала.

[amarao]

А какая польза от feature-файла и почему нельзя было обойтись тестами без вот этой псевдочеловекочитаемой ахинеи?

[Elufimov]

Бытует мнение что это позволяет обычным тестировщикам писать тесты, но всё разбивается в дребезги когда что-то перестаёт работать и всёравно нужно дебажить. Бытует мнение что это даёт читабельные тест кейсы, но разбрасывание по ходу теста статичных методов Given When Then которые также дёргают под собой логгер и/или allure выглядит так же читабельно. Бытует мнение что поддерживать тесты на кукумбере проще, но всё внезапно становится сложно когда нужно передавать состояние из шага в шаг или хочется прокидывать в тест сложные объекты. А когда приложение состоят из кучи страниц то шаги внезапно начинают дублироваться. Бытует мнение что кукумбер лучше структурировать тесты и возможно даже отказаться от page object, но даже в примерах в статье идёт вызов поиска по локаторам прямо в шагах, но при этом есть отдельно объектаная модель.

[amarao]

Я очень мало игрался с BDD, но я посмотрел на результат и вернулся обратно на pytest/testinfra. Я не понимаю зачем понятные выражения pytest'а заменять на текст, который на самом деле не текст, а потом писать под этот текст ещё и код. Лишние нажатия кнопок, да и только.

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

Вот пример очень крутого теста для свежесобранной операционной системы:

@pytest.mark.timeout(timeout=90)
def test_nginx_systemd_and_apt(ssh_backend, wait_for_port):
    '''
        This check performs a simple integration
        test: install nginx and check if it starts to reply
        at the port 80

        This test is intended for apt + systemd installations

    '''
    ssh_backend.Command.check_output('sudo apt-get install -y nginx')
    ssh_backend.Command('sudo systemctl start nginx')
    time.sleep(1)
    assert wait_for_port(port=80, timeout=10)

[sunagatov]

«но всё внезапно становится сложно когда нужно передавать состояние из шага в шаг или хочется прокидывать в тест сложные объекты». Скажу на примере фреймворка Gauge, но у Cucumber тоже есть такие механизмы — передача параметров между степами, они хранятся в рамках сьюта, их можно записывать и получать. Не скажу про «сложные объекты», т.к не указано, что именно нужно нужно передать.

[Iksanova]

Обычные тестировщики могут поддерживать feature — файлы, менять шаги при изменении функционала, в случае падения разобраться в чем возникла ошибка. Соглашусь с Михаилом, отчеты в Allure выглядять читабельно для всех членов команды, в т.ч. для аналитиков и PO.

[amarao]

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

[DmitriyTitov]

Лилия, подскажите, можно ли написать автоматические тесты для веб-интерфейса при условии что загрузка данных на странице в одних и тех же таблицах может занимать как 1 секунду так и 40 секунд.
Если да, то какой инструмент для этого наиболее прост?

[Iksanova]

Думаю, что лучше разобраться почему «загрузка данных на странице в одних и тех же таблицах может занимать как 1 секунду так и 40 секунд». Если это нормальное поведение системы, то добавить ожидание в цикле и условие, которое проверит, что таблица полностью загрузилась и можно продолжить проверку.

[DmitriyTitov]

А какой инструмент для этого самый простой? Я никогда ничего из автоматизации тестирования интерфейсов не использовал. Что бы мне такое взять чтобы просто и быстро?
Собственно в этом и была суть вопроса :)

[Iksanova]

Если нравится javaScript, то можно посмотреть в сторону Cypress. На поддержку может уходить много времени и поддерживает только chrome.

[Iksanova]

Ещё можно использовать Selenium + Python без отчётов, паттернов и bdd. Тоже быстрее будет, но при частом изменении функционала поддержка займет много времени. Вариантов много выбор зависит от конкретных потребностей на проекте.

[megamrmax]

Cucumberы (они же для каждого языка по своему зовутся) штука весьма прикольная если понимать где и как ее можно применить. Например если мы хотим тестировать API, то для этой задачи он(оно) вполне себе подходит. В компании где я работаю есть фреймворк который именно это и делает, при этом за три года его сущствования в «шаги» было внесено всего 3 или 4 изменения.
Однако мы отказались использовать огурцы для тестирования UI так как столкнулись с тем, что получаем очень много дублирования кода и повышенные затраты на содержание этого огорода. В итоге вернулись на голый код.
Как мне кажется, если тестер понимает ограничения этого подхода (или девелопер) или же в компании работают успешные манагеры, нанимающие толпы полуграмотных тестеров из одной карри-кантри — то Кукумбер вполне рабочий инструмент.

[Iksanova]

Да проекты есть разные, в нашем проекте Cucumber показал себя как вполне рабочий инструмент. Автотесты могут поддерживать функциональные тестировщики, что помогает им «доверять» результатам прогона автотестов и не тратить время на перепроверку результатов, что положительно сказывается на скорости выпуска релизов.

[redskif]

А ваш фреймворк для API самописный?
Что можете сказать про Karate DSL?

[Iksanova]

Да. Karate пока не использовала, посмотрю в его сторону. Спасибо:)

[redskif]

Лилия, посмотрите конечно. Но я товарища megamrmax спрашивал.

[djangoN]

Посмотрите в сторону selenide, тогда на надо будет использовать фабрику для инициализации элементов на странице. Cucumber также не особо нужен, излишний уровень абстракции.

[Iksanova]

Спасибо, уже смотрим.

[air_squirrel]

Наигрались c огурцом, если писать что то серьезное и под большой проект, то сталкиваешься с проблемами «шарить данные между степ классами» на помощь приходит DI из cucumber-spring, тогда зачем нам огурец, нет поддержки unit5 для io.cucumber, апдейт версии io.cucumber до одной из последних крешет проект если у вас idea 2019.xxx и понеслось…
https://youtrack.jetbrains.com/issue/IDEA-217391
В итоге ушли чисто в junit 5 без bdd

Скажите пожалуйста сколько времени у вас ушло на написание этих тестов с репортингом allure? По моим подсчетам макс полторы недели ?

[portable]

Какой di? Тредлокал мапа + xstreamconverter почти полностью решает проблему передачи любых объектов между шагами

[air_squirrel]

Threadlocal как вариант, но не наш

[Iksanova]

Не совсем понятно зачем в автотестам использовать Threadlocal ?

[air_squirrel]

Ну например, для scenario context чтобы шарить какие нибудь данные между степ шагами (классами).

[Iksanova]

Спасибо, почитаю

[air_squirrel]

Вам спасибо за статью!

[portable]

Если абстрагироваться от срача про необходимость использования кукумбера, то:
С точки зрения BDD писать шаги в стиле "нажата кнопка" или "поле заполнено" это антипатерн, не для этого он задумывался.
В свою очередь, выносить логику работы с элементами в степы это антипатерн с точки зрения page object.
А если получается, что это не bdd и не page object, то надо либо выкидывать кукумбер, либо, если он нужен, заменить page object на мапу (или несколько), где ключём будет содержимое вашей аннотации name, а значением — элемент. В обоих случаях переделать это все на селенид. Все это сведет к нулю количество бесполезного кода и сильно повысит читаемость

[Iksanova]

Уже переходим на селенид:)