Как вы тестируете ваши UI тесты?

общие вопросы
#1

Не секрет, что в большинстве случаев автоматизация через UI – это регрессионное тестирование.

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

Но, как убедится в том, что проверки (Assert’ы) были сделаны правильно.

Например, у меня нередко возникают ситуации, когда я читаю значение не из того поля или не того элемента.

Например, в результате того, что в переменной с ожидаемым значением была пустая строка, а в ошибочно взятом элементе на странице – было пустое значение – мой тест прошел.

Когда идет проверка формы, очень велик соблазн накопипастить один и тот же механизм взятия значения, но для разных полей.
Иногда, я забываю заменить айдишник поля. Так что получается, что для одного поля значение считывается 2 раза, а для другого – ни разу.

Я пришел к выводу, что необходимо проверять каждую проверку.
Делаю я это так:

  1. Вначале пишу проверку: Assert.Same(actualValue, “Expected to fail!”)
    Т.е, вместо значения expected вставляю некоторый мусор, который должен спровоцировать падение теста. – И надеюсь, что тест упадет.
  2. Потом, беру actualValue из лога ошибки Assert и вставляю его на место expected значения.
  3. Прогоняю тест еще раз и ожидаю passed

Для сравнения массивов и хэшей(словарей) – использую похожую технику. Также, временно добавляю, удаляю и модифицирую некоторые элементы, чтобы спровоцировать падение.

Знаю о существовании, но так и не пришлось применить на практике:

  • Библиотека ApprovalTests – позволяет валидировать и апрувать (одобрять) результаты тестов руками, при помощи инструмента сравнивания текста и сохранять эти апрувы для дальнейших проходов.
  • Мутационное тестирование – суть в том, что байт-код уже скомпилированного приложения, внедряются так называемые мутации: true заменяется в некоторых местах на false, знак больше – на меньше, число 42 на 43. И тому подобное. После, запускаются тесты, которые эти мутации должны выявить, т.е. – упасть.

Мне бы хотелось попробовать мутационное тестирование, но, пока нет времени на эксперимент.

А как вы тестируете ваши тесты?

#2

Точно также тестирую.
Я для себя взял за правило: если тест passed, то это не значит, что он дописан до конца.
Также я не редко даю посмотреть свой код коллегам: проводим code review тестов.

Точно в байт-коде? Мне казалось, что там именно компилируется “неправильное” приложение и от этого есть некая неприязнь забыть поменять всё назад в коде.

#3

Конечно, для скриптовых языков не всегда есть возможность менять байт-код, поэтому меняется исходный.

Вот интересная презентация по JavaScript мутациям:

#4

В моём случае проще. Так как, а основном, использую для написания коммерческое ПО, то, там скорее возникнет ошибка ненахождения элемента, чем возьмёт не тот элемент для сравнения. Поэтому у меня ситуация, скорее наборот. Если тест Fail, не факт, что он Fail. :smile: