Вы знаете, что что-то не так, если ваши тесты медленные, нестабильные и игнорируются. Я упоминал не обслуживаемый и трудный для записи? И, наконец, насколько легко / сложно настроить среду тестирования?

Написание тестов обычно болезненное и скучное занятие, но я знал, что мы справимся лучше. Итак, давайте посмотрим, как мы можем это сделать в JS. Я начал оценивать несколько инструментов, чтобы показать мощь JS. Конечно, экосистема JS настолько изменчива, что когда вы закончите читать этот пост, возможно, появится новый / блестящий инструмент (или нет).

Кукловод

С Puppeteer вы можете автоматизировать буквально все. Мы можем создавать тесты пользовательского интерфейса, запускать веб-парсер, делать скриншоты, создавать PDF-файлы, проверять покрытие кода и визуально сравнивать сайт. Кукловод управляет браузером Chromium напрямую через протокол DevTools ⚡.
Меня беспокоит то, что при написании тестов пользовательского интерфейса нам нужно писать много кода, который делает тесты подробными (waitForSelector, waitForNavigation, подождите и подождите еще немного). Не поймите меня неправильно, мы полностью контролируем ситуацию, но нам приходится писать много шумного кода, который может привести к неустойчивому коду.

Кипарис

Cypress был создан с учетом требований тестирования и обладает отличными функциями. Cypress запускает код в браузере, управляя браузером через его API. Веб-сайт загружается внутри iframe, а Cypress имеет доступ к реальным элементам DOM. Cypress имеет приятный контроль элементов, шаблон утверждения, боковую панель с выполненными тестовыми командами и моментальные снимки DOM. Я не мог настроить параллельное выполнение тестов, поэтому просто продолжаю. Тем не менее Cypress - отличный инструмент для тестирования.

Потом я влюбился в TestCafe.

Все остальные инструменты казались немного хакерскими и неудобными, но когда я начал использовать TestCafe, я почувствовал, что у меня есть суперспособности при написании тестов пользовательского интерфейса. TestCafe работает в Node. Он использует прокси-сервер для внедрения сценариев, которые имитируют действия пользователя, и оттуда имеет полный контроль.

Обсуждение дешево, поэтому позвольте мне показать вам код.

Я буду использовать приложение TodoMVC, и вы можете проверить тестовый файл на репозитории github.

npm i testcafe

Сначала я создал класс с селекторами страниц и приспособлением с начальной страницей:

С async await тесты выглядят такими чистыми и милыми:

Добавьте скрипт npm и запустите его или введите в терминале:

"test": "./node_modules/.bin/testcafe chrome tests/"

Утверждаем удаление задачи:

Есть много приятных функций, мы можем утверждать, сколько дочерних элементов имеет или утверждать класс элемента css. Лично мне не нравится, что nth (0) основан на нуле, потому что он зависит от css: nth-child (1), но мне нравится этот функциональный api.

С их красивым api действий мы можем делать много всего, как настоящий пользователь:

Теперь протестируем выполнение всех задач:

Чтобы сделать вещи более СУХИМИ (не повторяйтесь), мы можем использовать цикл for-of с await, но мы должны использовать Node 9+:

Где тесты терпят неудачу

Если утверждение не выполняется, мы получаем действительно хорошее сообщение об ошибке с номером строки и окружающим контекстом. Здесь я допустил ошибку в тесте, просто чтобы увидеть этот приятный результат:

Параллельно, черт возьми

Параметры интерфейса командной строки TestCafe

Кросс-браузерная поддержка:

$ testcafe chrome tests/
$ testcafe firefox tests/
$ testcafe ie tests/
$ testcafe safari tests/
$ testcafe all tests/

Эмуляция устройства:

$ testcafe "chrome:emulation:device=iphone 6" tests/

Без головы:

$ testcafe chrome:headless tests/

Скриншоты в случае сбоя теста:

$ testcafe chrome tests/ --screenshots-on-fails -s screenshots

Уменьшите скорость тестирования:

$ testcafe chrome tests/ --speed 0.5

Отладка при сбое теста:

$ testcafe chrome tests/ --debug-on-fail

И что лучше всего - параллелизм.

$ testcafe chrome tests/ --concurrency 8

Отладка

Поскольку он запускается из узла, серверная версия для отладки testcafe должна запускать его с --inspect или с --inspect-brk и размещать оператор debugger в любом месте тестового кода.
Клиентская версия отладки помещается t.debug() внутрь test, и testcafe приостанавливает выполнение. Другая версия на стороне клиента - запустить testcafe с флагом
--debug-mode, и мы можем продолжить выполнение теста вручную.

Работает на CI

В TestCafe есть отличная документация по популярным CI. Трэвис всегда мой первый выбор, когда мне нужна быстрая и качественная настройка. Вы можете проверить журнал заданий на предмет моего последнего выполнения теста. А вот .travis.yml:

Заключение

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

Надеюсь, вам понравится, TestCafe - действительно отличный инструмент, и с ним так красиво писать тесты.

Получите чашку кофе, проверьте Документацию TestCafe и напишите эти тесты ☕