Здесь, в SimpleReach, мы используем Ember.js в качестве нашего клиентского JavaScript-фреймворка с 2013 года. Благодаря постоянному использованию ember мы потратили больше времени на создание надежного комплексного набора тестов. Это ускоряет время разработки, позволяя нам поддерживать и реорганизовывать некоторые из старых частей наших приложений. Тестирование клиентского javascript, включающего промисы, взаимодействие с пользователем и внешние библиотеки, может быть утомительным и разочаровывающим, но нет ничего лучше, чем когда вы все делаете правильно.
Одна из самых больших проблем, с которыми мы столкнулись при создании нашего набора тестов, — это имитация сервисов в приемочных тестах. Когда вы хорошо имитируете службу, вы максимально приближаетесь к воспроизведению фактического поведения рассматриваемой службы. Это может потребоваться, поскольку служба обращается к внешнему источнику или объекту, который может быть недоступен. Это сложно, потому что вам нужно переопределить нативный код, но он должен отражать функциональность.
Недавно мы придумали самодокументирующийся шаблон многократного использования, чтобы облегчить нашей команде написание тестов в будущем. Сделав тестирование менее пугающим и более прозрачным, мы побудили нашу команду писать больше тестов в каждом PR, что ускоряет время разработки и вызывает меньше ошибок!
Он начинается с создания `tests/helpers/your-mock.js`, который, в свою очередь, создает функцию настройки и демонтажа, которую мы импортируем в наш `tests/helpers/module-for-acceptance.js`.
В качестве примера мы создадим простой макет, который заглушит службу флэш-уведомлений. Эта служба может отображать флэш-уведомления на странице после успешной или неудачной отправки формы.
В приведенном ниже коде мы создаем фиктивный сервис с функциями, соответствующими типам уведомлений. Все, что они делают, это помещают сообщения в хэш соответствующих очередей, называемых уведомлениями. Оттуда мы регистрируем фиктивную службу как `service:mockNotifications` и внедряем ее в приложение. Наконец, мы создаем две функции, называемые `setup` и `teardown`, чтобы поддерживать чистоту нашей среды. В будущем вы должны следовать этому плану для каждой службы, каждая из которых имеет функцию установки и отключения.
Далее, в «модуле-для-принятия» мы импортируем функции «настройка» и «разборка» и выполняем их в функциях «beforeEach» и «afterEach» (которые были сокращены для краткости). Важно отметить, что мы присваиваем импортированным функциям более конкретные имена. Таким образом, мы можем иметь много функций «настройки» и «разборки» в нашем «модуле для принятия», что важно в сложных средах с несколькими фиктивными службами. Поскольку мы уже создали несколько фиктивных файлов для каждой службы, мы можем импортировать столько, сколько нам нужно, при этом следуя схеме многократного использования.
Теперь все, что нам нужно сделать, это проверить уведомления! Мы импортируем ранее определенную переменную `notifications` с ее хэшем очередей и утверждаем, что она была заполнена уведомлениями и у них есть правильные сообщения.
В SimpleReach мы используем среду тестирования QUnit для внешнего тестирования. Поскольку Ember поставляется из коробки, с ним действительно легко начать работать, у него отличная документация и сообщество. Создать пользовательское утверждение было очень просто, если следовать задокументированным рекомендациям сообщества. Для получения дополнительной оценки вы можете создать собственное пользовательское утверждение QUnit, следуя приведенному ниже примеру. Ниже мы создаем утверждение, которое проверяет, существует ли тип сообщения в хэше импортированных уведомлений и имеет ли он определенный текст сообщения. Мы также передаем сообщение об успешном завершении теста.
Наконец, нам нужно зарегистрировать наши пользовательские утверждения перед запуском наших тестов. Мы делаем это, запуская экспортированную функцию `registerCustomAssertions` в `tests/test-helper` перед запуском `start`. Теперь вы избавите себя от двух утверждений, и ваши тесты станут более предписывающими! Победа есть победа в моей книге.
Этому процессу мы следуем для всех наших услуг. Это позволяет нам проводить всесторонние приемочные тесты и чувствовать себя уверенно при любых рефакторингах или создании новых функций. В будущем мы надеемся извлекать макеты сервисов в интеграционных тестах в аналогичный многоразовый план, который мы видели в наших приемочных тестах.
Об авторе:
Эндрю Фриман – инженер полного цикла из Новой Англии, выдающий себя за жителя Нью-Йорка, которому нравится сначала делать, а потом учиться.
