Pull to refresh

Comments 31

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

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

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

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

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

Я очень мало игрался с 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)
«но всё внезапно становится сложно когда нужно передавать состояние из шага в шаг или хочется прокидывать в тест сложные объекты». Скажу на примере фреймворка Gauge, но у Cucumber тоже есть такие механизмы — передача параметров между степами, они хранятся в рамках сьюта, их можно записывать и получать. Не скажу про «сложные объекты», т.к не указано, что именно нужно нужно передать.
Обычные тестировщики могут поддерживать feature — файлы, менять шаги при изменении функционала, в случае падения разобраться в чем возникла ошибка. Соглашусь с Михаилом, отчеты в Allure выглядять читабельно для всех членов команды, в т.ч. для аналитиков и PO.

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

Лилия, подскажите, можно ли написать автоматические тесты для веб-интерфейса при условии что загрузка данных на странице в одних и тех же таблицах может занимать как 1 секунду так и 40 секунд.
Если да, то какой инструмент для этого наиболее прост?
Думаю, что лучше разобраться почему «загрузка данных на странице в одних и тех же таблицах может занимать как 1 секунду так и 40 секунд». Если это нормальное поведение системы, то добавить ожидание в цикле и условие, которое проверит, что таблица полностью загрузилась и можно продолжить проверку.
А какой инструмент для этого самый простой? Я никогда ничего из автоматизации тестирования интерфейсов не использовал. Что бы мне такое взять чтобы просто и быстро?
Собственно в этом и была суть вопроса :)

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

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

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

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

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

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


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

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

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

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

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

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

Sign up to leave a comment.