Какой смысл издеваться над методом внешней библиотеки при модульном тестировании?

Question

Какой смысл издеваться над методом внешней библиотеки при модульном тестировании?

Допустим, у меня есть функция, которая использует библиотеку XYZ для получения текущего пользователя с использованием данного токена авторизации, а затем, еслион находит пользователя, возвращает действующую политику AWS:

export const getUser = async token => {
  const user = await XYZ.getUser(token)
  return {
    // valid policy
    context: user,
  }
}

Если указан неверный токен, getUser должен выдать ошибку.

• Какой смыслпроверки этой функции, если XYZ.getUser уже хорошо протестирован?
• Зачем издеваться над getUser вместо использования настоящего?

Answer 1

это восходит к определению и использованию модульных тестов.

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

Модульные тесты по определению не предназначены для прикосновения к каким-либо внешним системам, таким как, помимо прочего, файлы, API, базы данных, все, что требует выхода за пределы логической единицы, то есть кода, который вы хотите протестировать.

Существует множество причин, среди которых скорость выполнения. Вызов API или использование стороннего вызова занимает некоторое время. Это не обязательно проблема, когда вы смотрите на один тест, но когда у вас есть 500 тестов или больше, задержки будут важны. Основная идея заключается в том, что вы должны выполнять свои модульные тесты постоянно, очень быстро, вы получаете немедленную обратную связь, что-то сломано, я что-то сломал в других частях системы. В любой зрелой системе вы будете запускать эти тесты как часть процесса CI / CD, и вы не можете позволить себе слишком долго ждать их завершения. нет, они должны запускаться за считанные секунды, поэтому у вас есть правила того, чего они должны или не должны касаться.

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

Что если вы позвоните стороннему API, и он не будет обслуживаться? Значит ли это, что вы не можете протестировать свой код из-за них?

Теперь, что касается насмешек, не злоупотребляйте ими слишком сильно: если вы кодируете функционально, вы можете избавиться от большого количества насмешек. Вместо передачи или хард-кодирования зависимостей передайте данные. Это позволяет очень легко изменять входные данные без особой насмешки. Вы некоторое время тестируете систему, используя тесты интеграции / e2e, это дает вам уверенность в том, что ваши зависимости разрешены правильно.

Answer 2

Вы не хотите вызывать фактический HTTP-запрос для XYZ.getUser(token) по следующим причинам.

1) Цель юнит-тестирования состоит в том, чтобы проверить определенное поведение, а в вашем случае - проверить, что ваша getUser функция действительно работает.

2) Вы не захотите делать фактический запрос к бэкэнду, поскольку это обычно означает запись / чтение / удаление чего-либо из базы данных. Во многих случаях не стоит слишком усложнять ваше модульное тестирование, поскольку такие операции не следует тестировать во внешнем интерфейсе, поскольку вы захотите ограничить и упростить ваше модульное тестирование для тестирования очень специфического поведения.

3) Поскольку основной целью является проверка описанного выше поведения, вам нужно упростить и ограничить то, что вы тестируете. Таким образом, вам необходимо понимать, что модульное тестирование сетевых запросов XYZ.getUser(token) должно выполняться на стороне сервера, а не на стороне клиента (или на стороне клиента).

4) Путем насмешливого ответа от XYZ.getUser(token) мы можем смоделировать несколько сценариев и ответов, таких как успешные ответы (Код 200 в порядке) и другие типы ошибок (ошибки бизнес-логики из бэкэнда или сетевые ошибки, такие как ошибка 400, 500 и т. д.). Это можно сделать путем жесткого кодирования требуемых ответов JSON из XYZ.getUser(token) в различных типах сценариев, которые необходимо протестировать.