Ниже приведен список инструментов, которые я использую для интеграционного тестирования:

  • Mocha в качестве тестового исполнителя на серверной части; в то время как я использовал Karma на интерфейсе с Angular
  • ChaiJS как библиотека утверждений; Jasmine также является прекрасным решением, которое я использовал во внешнем интерфейсе.
  • SinonJS для шпионажа, заглушки и имитации классов, объектов и функций
  • Moxios для имитации запросов API, выполненных с использованием Axios.
  • Proxyquire для заглушки зависимостей
  • FakerJS для генерации случайных поддельных данных

Контрольный список:

  • [ ] Требуются модули
  • [ ] Основной блок описания
  • [ ] Верхний уровень до и после блока
  • [ ] Блок Describe для каждой (общедоступной) функции файла
  • [ ] Оператор It для основного потока для большей части покрытия кода
  • [ ] Запись ожидаемого или утвержденного значения на основе возвращаемого функцией значения (сначала тест должен завершиться ошибкой)
  • [ ] Напишите минимальный код, чтобы сделать тест успешным (с наибольшим потоком покрытия, если не сложно)
  • [] Зависимые функции-заглушки в том же файле или другом файле для модульного тестирования этой функции
  • [ ] Пройти достаточное количество тестов для охвата кода от 75% до 80%

Примечания

Чтобы файлы тестирования были короткими и простыми, я обычно пишу отдельный файл для файла службы или API. Например, у login.service.ts в тестовой папке есть файл с похожим именем.

Затем я добавляю основной блок описания для именования пакета тестирования файлов, например. Login Testing Suite или Login Integration / Unit Suite. Если файл для тестирования слишком длинный, я обычно стараюсь разделить тесты на несколько файлов, так как в противном случае коды станут слишком длинными для выполнения.

Ниже основного описания я пишу глобальные переменные, которые будут использоваться в этом файле, например. sandbox = sinon.createSandbox(), который позволяет мне ссылаться на песочницу где угодно, чтобы заглушить или имитировать функции.

Личный совет:

Если я пишу тесты для устаревшей системы, я сначала пишу тестовые коды в простой и прямолинейной манере, просто чтобы они прошли. После этого я затем организую переменные для повторного использования, если это необходимо, например, отправив sandbox.stub(file, ‘functionName’).returns(true) в оператор выше, чтобы я мог использовать его в следующем тесте.

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

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

Я в основном заглушаю все другие когнитивные усилия для системы аутентификации, такие как ожидание компиляции из Webpack, загрузка страницы входа, ввод учетных данных и проверка результата вручную.

Первоначально опубликовано на http://206.189.26.183 11 июля 2019 г.