[БЕЗ_ЗВУКА] Итак, в прошлом видео я демонстрировал, каким образом можно осуществить запрос на какой-то внешний сервис. И для демонстрации этого я поднимал прямо в той же программе веб-сервер, для того чтобы в него ходить. Это не всегда удобно, и иногда мы хотим протестить либо HTTP hadler, то есть функцию, которая будет обрабатывать наши запросы, либо мы хотим протестировать функцию, которая входит в какой-то внешний сервис и получает оттуда ответ, и мы хотим протестировать ее. В этом видео мы проговорим про то, какие инструменты предоставляет Go для этого. Итак, допустим, у нас есть функция GetUser — это HTTP handler. Она принимает параметр, и в зависимости от этого параметра нам отдает какой-то результат. Мы хотим ее протестировать. Да, мы можем как-то мокать или что-то еще, какие-то подставлять значения туда, но в Go есть для этого специальная функция. Есть пакет net/http/httptest — вот так он называется. И там находится вспомогательная функция. Например, там есть Request и есть Recorder. Соответственно, что мы можем сделать? Мы можем подготовить этот тестовый запрос, то есть он будет ровно таким, который придет в вашу функцию. Не тот, который вы отправляете на какой-то внешний сервис, а именно тот, который придет в этот сервис. Можем подготовить Recorder и уже запросить как раз таки функцию с этими параметрами. И дальше уже проверять, что там есть, все ли хорошо, тот ли статус код вернулся, тот ли результат вернулся. То есть мы можем из вот httptest.NewRecorder вернуть результат — это тот response, который получила бы ваша функция. Там есть Header, там есть Body, там есть статус код. В данном случае я вычитываю весь Body, привожу его к строку и просто сравниваю с эталоном, вот так. Если тут что-то или нет, запускаем request_test. Тест проходит, все хорошо. Теперь как быть, если нужно с другой стороны? То есть протестировать какую-то внешнюю, подменить какой-то внешний сервис. Это можно сделать, используя тот же пакет httptest. Рассмотрим следующим пример: у нас есть функция, у нас есть структура «корзина», и у нее есть метод Checkout (оплатить). В данном случае я привел упрощенную — там, конечно, должна быть сумма и прочее, прочее, но для примера подойдет. Есть URL платежного шлюза или платежного сервиса, куда нам нужно сходить, чтобы списали с нашего баланса. И вот, допустим, мы создаем сразу URL, по которому мы идем, добавляем там id. И дергаем его Get'ом. Все, не заморачиваемся, потом там проверяем ошибки, закрываем, вычитываем Body, и распаковываем json, и опять возвращаем ошибку. И мы хотим проверить, что эта функция, что полностью мы покрыли все возможные результаты. Может быть, test coverage построить, может быть, у нас цель — достичь 100 %-го. Если просто ходить в какой-то внешний сервис, во-первых, на реальном сервисе у нас будут списывать деньги. Ну и, конечно, мы не всегда можем гарантировать, что он вернет нам ошибку или там будем таймаут, потому что на той стороне люди наверняка стараются, чтобы этого не происходило. Как это проверить? Очень хорошо, что у нас есть PaymentApiURL, поэтому мы можем поднять у себя сервер и туда отправить, в этот PaymentApiURL уже поставить нужное нам значение нашего локального сервера. Итак, рассмотрим. Вот мои тест-кейсы, их четыре. Вот я создаю сервер, указываю CheckoutDummy, то есть функцию, которая будет обрабатывать приходящие туда запросы. Этот сервер начнет слушать на каком-то случайном порту, и мне вернется его URL. Теперь я могу уже, не стесняясь, отправлять туда все нужные мои запросы, зная, что они придут ко мне. Не в какой-то внешний сервис, а ко мне. И я проверяю, что была ли там ошибка, либо там, наоборот, ошибки не было. И мне вернулся ровно тот результат, который я ожидал. Ну и в конце я выключаю этот сервер. Вот. Давайте посмотрим функцию CheckDummy еще наконец. CheckDummy — это функция, которую я принимаю в свои входящие параметры, которую я отсылаю на этот сервер, и возвращаю какой-то нужный мне результат. То есть я могу вернуть успешный запрос, могу вернуть плохой запрос, но как будто бы это штатная ситуация, могу вернуть, вообще, кривой json, либо же могу вернуть просто 500 server, значит он вообще недоступен. То есть очень удобно, когда вы можете подменить какой-то внешний сервис своим, написать там все нужные вам тест-кейсы и проверить нужный ваш код. При этом опять-таки это все предоставляет вам стандартная библиотека. Давайте запускать. [ШУМ] [ШУМ] Вот мой тест отработал, все успешно, я прошел все случаи: и ошибки, и кривой json, и отсутствующий баланс. Таким образом вы можете покрыть все ваши все ваши функции, который либо ходят куда-то, либо принимают откуда-то что-то, без того чтобы очень долго городить какую-то необходимую инфраструктуру вокруг этого. Вы используете прямо в своем тесте, прямо в своем коде. Это очень удобно.
