Ниже приведен список инструментов, которые я использую для интеграционного тестирования:
- 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 г.