UIT, опыт CRM (и не только)

1.

UIT, опыт CRM (и не
только)

2.

Какой план
1) Написать тесткейс
2) Написать компоненты
3) Написать тест
4) Анжуманя
5) Проверить скорость и стабильность

3.

Тест кейс
1) Что проверяет
2) Предусловия
3) Шаги

4.

Компоненты
LognexPage
или просто класс?
1) Плюсы LognexPage
a) Можно использовать com.lognex.util.LognexPagesFactory#navigate и обвязка с
кешированием
b) Можно создавать с помощью @TestPage
c) Из коробки можно использовать @FindBy (сомнительный плюс)
2) Минусы
a) Содержит много мусорных методов, которые мешают после искать
нужный метод

5.

Вывод
Если компонент - страница на гвт и типовая, то окей использовать
LognexPage - в остальных кейсах - сильно избыточно
p.s. таких новых вряд ли будет появляться, но вдруг.

6.

@FindBy
Минусы
1) Каждое обращение делает поиск элемента (медленно)
2) Не умеет в поиск относительно элемента (не имеет контекста, а тянуть
контекст - ухудшает понимание)
3) Ищет даже display: none элементы
Плюсы
1) Каждое обращение делает поиск элемента (не будет StaleElementReferenceException)
2) Удобно писать (если поиск Глобального элемента)
3) Можно использовать не только с WebElement но и TypifiedElement (e.g. Link, Button, Checbox)

7.

Видишь кнопку, и я нет, а она есть
Не забываем, что для кеширования
виджетов приложений сделано
кеширование страниц и некоторые
части просто используют (display:
none) (но по ним идет поиск).

8.

К чему пришли в команде CRM
1) Страница\Сайдпейдж\Попап - набор методов, которые возвращают
компоненты (не WebElement-ы, а что-то более осмысленное, типо
ru.yandex.qatools.htmlelements.element.Button или что-то из com.lognex.primitives.react)
2) Можно посмотреть сорсы, и если используется компонент из КБ, то
нужно реализовать его в com.lognex.primitives.react
3) Использование @FindBy не дает преимуществ по скорости, но не умеет в
поиск относительно parent элемента
a) Приходится костылить для поиска относительно parentString

9.

Посмотрим код

10.

Как писать тесты
1) 1 ТестКейс - 1 тестовый класс
2) Предусловия в init()
3) Все что можно сделать в апи - делается в апи (если это не важно для
кейса)
4) В тестах не используем driver.findElement() и его аналогов

11.

Что делать, если тест требует правок в коде
Вариант 1:
Сделать правки, запушить, дождаться сборку, залить на окружение, написать тест
Вариант 2:
Сделать правки, собрать локально и поднять локально, запустить тест против локального окружения
docker compose up -d main billing remap-12 exchange (при необходимости поднять что-то еще)
---------------------------------------------------server.url=http://localhost
api.url=http://localhost
billing.url=http://localhost:8083
billingapp.url=http://localhost:8083/app
wiremock.enabled=false
namespace=localhost

12.

Что делать, если в sdk чего-то нет, а в апи есть
Вариант 1 (добавление в sdk):
1) Создай тикет в sdk
2) Выполни его и зарелизь
3) Поменяй версию sdk в проекте uit
4) Profit
—
Вариант 2 (правки только в проекте uit)
1) Сделай то что нужно в самом проекте uit, например, com.lognex.util.api.RoleEndpoint

13.

Работа с ускорением тестов
Исследование:
1) В tms-summary посмотреть на slow e2e - найти медленные тесты
a) Но мы сделали свой дашборд CRM slow e2e
2) Посмотреть эти медленные прогоны в кибана
a) app: uit and thread: test_MS_Script_04 and test_result: *
3) Убедиться, что прогоны медленные (а не проблема в browser_session_initialization_time_ms)
4) Посмотреть отчет аллюра по шагам (можно взять медленный прогон по
кибане, взять в рамках какого пайплайна он был, и в пайплайне открыть
отчет) - и оптимизировать медленные шаги (например, через апи)

14.

Работа с мигалками
Запрос в кибане
app: uit and test_result: * and owner: team-crm and not test_result : "success" and not stackTrace: *registerFast* and not stackTrace: *wiremock* and not
stackTrace: *ApplicationUnavailableException*
Поиск топа - и исправление причины мигания у топа