Как обрабатывать много вызовов `mockImplentationOnce` - PullRequest
Новая
       31

Как обрабатывать много вызовов `mockImplentationOnce`

0 голосов
/ 03 октября 2019

Я пишу интеграционные тесты для класса, у которого много запросов. Запросы выполняются через HttpClient синглтон.

Так что, чтобы не делать реальных запросов, я высмеиваю все вызовы на HttpClient. Проблема в том, что у меня слишком много запросов.

  1. HttpClient.get вызывается для получения токена.
  2. HttpClient.get вызывается для получения ресурса.
  3. HttpClient.get вызывается для выборки всех клиентов с этого ресурса.
  4. HttpClient.get вызывается для проверки наличия одного клиента в другом API.
  5. Условно: HttpClient.post вызывается длядобавьте этого одного клиента в API, если он не существует.
  6. HttpClient.post вызывается для добавления ресурса в другой API.

На самом деле это немного сложнее, чемПотому что некоторые из этих вызовов выполняются несколько раз (внутри цикла), но вы получите картину.

Я написал тестовый пример для каждого сценария. Один тестовый пример для имитации неудачного запроса на получение токена, другой для имитации неудачного запроса на выборку ресурса и т. Д.

Для этого я написал «счастливый» сценарий - где все идет хорошо -, используя mockImplementationOnce. Мой beforeEach выглядит примерно так: 

tokenResponse = { body: { token: 'some-token'}, status: 200 }
HttpClient.get.mockImplementationOnce(() => tokenResponse)
tokenResource = { body: <some-fixture-with-resources>, status: 200 }
HttpClient.get.mockImplementationOnce(() => tokenResource
(...)

Чтобы написать сценарии, я переназначил возвращаемую переменную 

it('fails to fetch the token', () => {
  tokenResponse = { status: 500 }

  // code that calls my class
  // code that asserts that an error was thrown
}

В любом случае мне удалось написать простые тестовые случаи для всех сценариев. , но у моего beforeEach есть гигантский шаблон. Кроме того, теперь я хочу написать более сложные тестовые случаи, когда запрос выполняется несколько раз (n клиентов> 1). Работать со всеми приборами и отслеживать отдельные макеты становится довольно сложно.

Это общая проблема? Есть ли более простой способ обработки ложных реализаций? Я думал о чем-то вроде mockImplementationNth, но ничего не смог найти.

Ps .: Изменить сам код сложно, потому что это устаревший код, а API немного неуклюжий.

1 Ответ

0 голосов
/ 03 октября 2019

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

describe('Integration test', () => {
  beforeEach(() => {
    setupMocks()
  })

  it('goes well', () => {
    expect(myClass.execute()).resolves.toBe(true)
  })

  it('fails to fetch the token', () => {
    overrideMocks('token-failed')
    expect(myClass.execute()).rejects.toEqual('some-error')
  })

  (...)
})

По крайней мере, тестовые примеры будут выглядеть проще.

...