Flaky tests. Метод.

Flaky tests
Андрей Солнцев
Метод
twitter.com/asolntsevasolntsev.github.io/ru/video/

В предыдущих сериях
“Flaky tests”
SeleniumCamp 2018
● Примеры
● Профилактика
“Flaky tests 2.0”
DelEx 2019
● Анимация
● Видосики
https://asolntsev.github.io/ru/video/

В предыдущих сериях
“Flaky tests”
SeleniumCamp 2018
● Примеры
● Профилактика
“Flaky tests 2.0”
DelEx 2019
● Анимация
● Видосики
Сегодня:
● Порядок вещей
● Метод

● Тратите время!
● Пропускаете реальные ошибки
● Пропускаете usability issues
● Теряется доверие к тестам
Flaky test
- это тест, который падает иногда

Ой, 30 тестов упало.
Надо изучить!
… Впрочем,
П……У….. !

Ой, 30 тестов упало.
Надо изучить!
… Впрочем,
Перезапущу!

Как вы это протестируете?
1. Клик “Сохранить”
2. Надпись “Сохраняю…”
3. Клик “Ок”
4. Надпись пропадает

Тест:
1. “Сохранить”
2. “Сохраняю…”
3. “Ок”
4. Пропадает
$(“.save”).click();
$(“.saving”).should(appear);
$(“.ok”).click();
$(“.saving”).should(disappear)

3. “Ок”
$(“.ok”).click();
● Автоматические ожидания
● Решает 90% флейки тестов
selenide.org
Тест:

Усложняем задачу
2. Надпись “Сохраняю…” (N секунд)
3. Надпись пропадает САМА

Тест:

Что может пойти не так?

Вариант 1: шустрый браузер
FAILED

Вариант 2: тормознутый браузер
1) “Сохранить” $(“.save”).click();
FAILED
2) “Сохраняю…”
> 4 сек
3) Пропадает

Компромисс 1
FAILED
Идём на компромисс.
Отказываемся от этой проверки.

Компромисс 2
НЕ НАХОДИТ БАГУ
Идём на компромисс.
Отказываемся от этой проверки.

Итак,
как надёжно проверить
кейс
“Сохранить”?

Как надёжно проверить
кейс “Сохранить”?
Правильный ответ:
НИКАК!

Почувствуй разницу:
3. Проходит время
Мы контролируем Мы НЕ контролируем

Почувствуй разницу:
3. Проходит время
Тест надёжный Тест ненадёжный

Порядок в тесте:
1. Act
2. Assert
3. Act
4. Assert
...

Порядок в тестах
1. Act
2. Assert
3. Assert
4. Assert
1. Act
2. Assert
3. Act
4. Assert
5. ...
Этот принцип - на каждом шагу!

Пример:
Автосохранение
видео

Логи AUT и теста:
10:59:12,865 UITest click.before <a>1 Contact and Addresses</a>
10:59:13,121 UITest click.before <button>Start filling</button>
10:59:13,686 UITest click.before <button>Forward</button>
10:59:13,851 UITest click.before <a>5 Preview</a>
10:59:13,905 request POST /loanapplications/mortgage/save ...
10:59:14,010 UITest click.after <a>5 Preview</a>

Логи AUT и теста:
click.before <a>1 Contact and Addresses</a>
click.before <button>Start filling</button>
click.before <button>Forward</button>
click.before <a>5 Preview</a>
POST /loanapplications/mortgage/save ...
click.after <a>5 Preview</a>
click.before <a>5 Preview</a>
click.after <a>5 Preview</a>
POST /loanapplications/mortgage/save ...
Когда тест упал:

Хорошая идея -
совместить логи
теста и приложения

Но как же решить
нашу задачу
с автосохранением?

Как-то контролировать порядок!
1. Клик “страница 1”
2. Дождаться автосохранения
3. Клик “страница 2”
4. Дождаться автосохранения
5. ...
Но как?

Как дождаться автосохранения?
1. Надпись “сохраняю…”
2. Иконка типа “дискета”
3. Через JavaScript “jQuery.active”
Нет.
Всё это мы не контролируем.

В AUT: добавляем признак
function autosaveDraft() {
self.form.removeClass('autosaved');
self.form.addClass('autosaving');
$.post(...)
.then(() => {
self.form.addClass('autosaved');
})

В тесте: проверяем признак
// заполняем форму, кликаем “Дальше”
$("#form").shouldHave(cssClass("autosaving"));
$("#form").shouldHave(cssClass("autosaved"));
А вдруг он остался от
предыдущего
автосохранения?

В тесте: проверяем признак
// Arrange:
executeJavaScript("document.getElementById('form
').classList.remove('autosaving')");
// Act: заполняем форму, кликаем “Дальше”
$("#form").shouldHave(cssClass("autosaving"));
$("#form").shouldHave(cssClass("autosaved"));

Unit-test
1. Arrange
2. Act
3. Assert
1. Arrange
2. Act
3. Assert
4. Arrange
5. Act
6. Assert
7. ...
AAA -
на каждом шаге!
UI test
Шаг 1
Шаг 2

https://seleniumcamp.com/talk/arrange-mazafaka/

Arrange!
Перед каждым шагом:
1. А всё ли готово?
2. А всё ли закончилось на предыдущем
шаге?
3. А обнулилось ли состояние?
4. А не грузится ли там в углу какая-нибудь
предыдущая хреновина?

Хочешь поймать
флейки тест
-
думай как флейки тест!

Пример:
Три-четыре
видео

Есть ﬂaky тест
$$("#devices .device").shouldHave(size(4));
● В 99.9% запусков он зелёный.
● Но иногда падает.
● Потому, что элементов не 4, а 3.

Изредка тест ломается:
List size mismatch: expected: = 4, actual: 3
Elements: [
<tr class="device">BlackBerry</tr>,
<tr class="device">Lumia</tr>,
<tr class="device">HTC</tr>
]

Смотрим тест вдумчиво:
$(".remove-device").click();
$$("#devices .device").shouldHave(
texts("BlackBerry", "Lumia", "HTC")
);

Смотрим тест вдумчиво:
);
Почему строк
4, но текста 3?

Исправленный тест:
);

Пример:
Ожидается -1 строк

Правильный тест (вроде бы?)
@Test
public void closeDeposit() {
fastLogin("/deposits");
int openDeposits = $$("#deposits tbody tr").size();
// bla-bla-bla закрыть депозит
$$("#deposits tbody tr").shouldHave(size(openDeposits - 1));
}

ARRANGE
Правильный тест (вроде бы?)
@Test
$$("#deposits tbody tr").shouldHave(
size(openDeposits - 1)
);
}
ACT
ASSERT

Но иногда он падает:
List size mismatch: expected: = -1, actual: 3, collection: #deposits tbody tr
Elements: [
<tr>73456 810 0 3331 0007779 Topupable 1 year 2.35% 25.04.2020 Active</tr>,
<tr>Deferred Deferred 6 months 3.67% 01.07.2017 Deferred</tr>,
<tr>Deferred Deferred 6 months 3.67% 01.07.2017 Deferred</tr>
]
Их и правда 3:
Но тогда что это
за хрень?

ARRANGE
Это халтура, а не ARRANGE!
@Test
);
}
Список ещё не успел
подгрузиться

Когда тестируешь UI
-
ты не можешь
доверять UI

ARRANGE
Вот правильный ARRANGE:
@Test
);
int openDeposits = DB.select(“count(*) from deposits”);
$$("#deposits tbody tr").shouldHave(size(openDeposits));

Вот правильный ARRANGE:
@Test
int openDeposits = DB.select(“count(*) from deposits”);
$$("#deposits tbody tr").shouldHave(size(openDeposits));
● Доверенный источник
○ SQL
○ API
○ Что угодно
● только НЕ ЧЕРЕЗ UI

Пример:
Сотри за мной нежно

Как подчищаются данные:
@After
public void deleteRegistration() {
if ($("#turnoff").is(visible)) {
$("#turnoff").click();
}
}

Предыдущий тест:
| ...
|.alert-success |should have(text 'done successfully') |PASS |
|#sbp-turnoff-confirmation-button |is(visible) |PASS |
|#sbp-turnoff-confirmation-button |click() |PASS |
|#sbp-turnoff-button |click() |PASS |
+---------------------------------+----------------------+----------+----------|
| ...
|.alert-success |should have(text 'done successfully') |PASS |
|#sbp-turnoff-confirmation-button |is(visible) |PASS |
+---------------------------------+----------------------+----------+----------|
А когда наш тест упал:

Неправильно:
@After
public void delete() {
...
}
Правильно:
@Before
...
}

Неправильно:
@After
if ($(...)
.is(visible)) {
...
}
}
Правильно:
@Before
DB.executeSQL(
“delete from orders”
);
}
● Доверенный способ
○ SQL
○ API
○ Что угодно
● только НЕ ЧЕРЕЗ UI

Метод (изучения флейки теста)
1. Создать ветку в GIT / джобу в CI
2. Гонять только этот тест 1000 раз
3. Проверить гипотезу
4. Повторять шаги 2-3 (пока не позеленеет)

Пример
1. Клик “заказать карту”
2. Браузер зависает
org.openqa.selenium.TimeoutException:
timeout: Timed out receiving message from renderer: 10.000

Проверяем гипотезу
● Поменял картинки на маленькие (1KB) -
● билд не упал ни разу за два дня:
Гипотеза:
размер (картинок)
имеет значение

● Добавил 10x больших картинок -
● билд стал падать чаще:
Проверяем гипотезу
Похоже, правда!

Вылечил флейки тест
● Отрефакторил страницу,
● чтобы все картинки не грузились сразу.
● + сжал маленькие картинки
● Тест больше не падает

Значит,
Он упадёт
завтра!

Следить за тестами -
Это как печь зефир

Нужно следить постоянно,
Иначе может подгореть

Нужно следить постоянно,
Иначе может подгореть
Нужно много времени
И терпения

Андрей Солнцев
@asolntsev
asolntsev.github.io
ru.selenide.org

Flaky tests. Метод.

More Related Content

What's hot (11)

Similar to Flaky tests. Метод. (14)

More from Andrei Solntsev (20)

Flaky tests. Метод.