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


(Дмитрий Жарий) #1

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

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

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

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

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

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

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

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

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

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

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

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

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


(Dmitriy Zverev) #2

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

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


(Дмитрий Жарий) #3

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

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

Mutation Analysis for JavaScript Web Applicaiton Testing SEKE2013 from nkazuki

(Максим Таран) #4

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