Оригинальная статья: Daniel Kuroski – Working an application in Vue.js with TDD — An extensive guide for people who have time — part 4

Это четвертая часть в серии статей:

• Part 1: Настройка и первый тест
• Part 2: Улучшаем UserView
• Part 3: Тестирование store и остальных компонентов слоя презентации
• Part 4: Тестирование службы запросов API
• Part 5: Добавление и тестирование со сторонними зависимостями

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

Теперь перейдем к последней части приложения, которое необходимо протестировать, – службе, отвечающей за обработку запросов к Github api.

Тестирование сервиса запросов API

tests/unit/api.spec.js

import flushPromises from 'flush-promises'
import nock from 'nock'
import api from '@/api'
import userFixture from './fixtures/user'

describe('api', () => {
  it('searches for the user', async () => {
    // arrange
    const expectedUser = 'kuroski'

    const request = nock('https://api.github.com')
      .get(`/users/${expectedUser}`)
      .reply(200, userFixture)

    // act
    const result = await api.searchUser(expectedUser)
    await flushPromises()

    // assert
    expect(result).toEqual(userFixture)
    expect(request.isDone()).toBe(true)
  })
})

Это наш последний тест. Единственное отличие от того, что было до сих пор, заключается в использовании новой зависимости, которую мы установили в начале проекта nock.

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

В нашем случае в строки 11 мы указали nock для наблюдения любого запроса GET для URL: https://api.github.com/users/:username, далее nock перехватит это и возвращает ответ со статуса 200 с нашей fixture.

Затем мы вызываем наш сервисный метод, передавая пользователя используем flushPromise, чтобы гарантировать, что все promises будут “резолвены” с этого момента.

Для фазы asserts мы хотим гарантировать, что результатом нашего сервиса будет наша userFixture, гарантируя таким образом, что был сделан запрос на ожидаемый URL, который мы mocking с nock.

Наконец, мы хотим гарантировать, что был вызван mocked URL в nock.

Наш тест провалится, так как у нас пока нет никакой реализации. Давайте сделаем это.

src/api.js

import axios from 'axios'
import httpAdapter from 'axios/lib/adapters/http'

const instance = axios.create({
  baseURL: 'https://api.github.com',
  adapter: httpAdapter,
})

export default {
  searchUser(username) {
    return instance
      .get(`/users/${username}`)
      .then(result => result.data)
  }
}

Наконец, у нас есть наш сервис, чтобы делать запросы.

Мы используем axios, библиотеку, которая помогает нам делать HTTP-запросы.

В строке 4 мы создаем экземпляр axios для запросов к API Github.

Адаптер, который мы передали в качестве конфигурации, необходим для того, чтобы мы могли использовать axios с nock. Это позволяет нам настроить то, как axios обрабатывает запросы, поэтому nock может перехватывать эти запросы.

В строке 10 у нас есть наш метод, который получает имя пользователя, и возвращает запрос GET для API Github.

В строке 13 мы получаем ответ на запрос и возвращаем свойства data запроса. Я делаю это здесь, потому что axios меняет результат и инкапсулирует ответ в этом свойстве.

Таким образом, мы завершили все тесты в нашем приложении.

---

Давайте посмотрим, как это работает?

Теперь мы можем наконец увидеть результат нашей работы. Запустим команду:

npm run serve

Что мы видим?

Совершенно ничего! Но … конечно, нам нужно создать маршрут для нашего компонента 😆

src/router.js

import Vue from 'vue'
import Router from 'vue-router'
const UserView = () => import('@/views/UserView')

Vue.use(Router)

export default new Router({
  mode: 'history',
  base: process.env.BASE_URL,
  routes: [
    {
      path: '/',
      component: UserView
    }
  ]
})

Готово. Вот и все:

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

В итоге мы получили полное приложение, практически не видя его. И что самое лучшее, у нас все основные части, полностью покрыты тестами 😍

---

Заключение

В этой четвертой статье мы сделали:

• Мы протестировали сервис, отвечающий за отправку запросов на Github
• Мы завершили наше приложение 😃

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

• Nock
• Axios

Поскольку есть ряд функций, которые мы можем использовать с этими библиотеками, а также не ограничиваясь ими, существуют другие библиотеки, которые выполняют такую же работу, например: jest-axios-mock.

Также в качестве предупреждения, рассмотренный способ тестирования не заменяет интеграционные и e2e-тесты. Мы гарантировали, что приложение будет работать, при определенном API которое возвращает то, что мы ожидаем. Если когда-нибудь Github изменить свое API, изменит его адрес или изменит его формат ответа (это крайне неправильно), наше приложение сломается.

В следующей статье мы добавим стороннюю библиотеку компонентов и обновим наши тесты для ее использования.

Следующая часть
Твиттер автора оригинальной статьи : @DKuroski