В предыдущей статья я переписал свой старый и надежный метод для интеграции с api и отправки post запроса. Теперь я хочу проверить, что все работает и в скользь затронуть тему тестирования.
Тестирование это неотъемлемая часть разработки. И я говорю не про тестирование графического интерфейса или тестирование бизнес правил - я говорю про backend. Про ту часть, о которой большинство пользователей и не догадываются. В большинстве случаев, если у пользователя не работает мобильное приложение плохие оценки получает именно мобильное приложение. Но все разработчики всегда в одной лодке и задача backend разработчика не в том, чтобы выдавать код, который работает без ошибок, а хотя бы предсказуемый код. Для этого есть разные способы - самый простой это коды ошибок в запросе api. Если 200 все хорошо, а не 200 все плохо. И в большинстве случаев все так и работает, но на деле же помимо 200 есть множество кодов ошибок, и помимо этого также можно ввести свою внутреннюю ошибку, например код 402 - значит что то не так заполнено, можно расширить и добавить внутренний код например 701 в тело ответа и тогда frontend сможет подсветить не корректно заполненное поле.
Я обязательно вернусь к этой теме и раскрою ее полноценно, но возвращаясь к теме тестов, хочу сказать, что тесты нужны даже чтобы просто проверить работает/не работает. Когда у тебя api, в котором 200 самописный библиотек и нет тестов, чтобы проверить что либо - нужно запустить api. Дождаться холодного старта в Postman вызвать метод, предварительно описав контракт и заголовки. А иногда и предварительно авторизоваться, чтобы получить токен. Это занимает массу времени и зачастую backend просто полагается на свой опыт и выкладывает как есть на dev (а иногда и сразу в prod).
И получает гневный комментарий от frontend разработчика "опять не работает", просит скинуть лог запроса, проганяет все через дебаг, исправляет ошибку и снова отправляет в dev. Ну и дальше все зависит от удачи... Либо if либо while.
Предположим, что новая фича или рефакторинг коснулся только одной из этих 200 самописных библиотек и для того, чтобы проверить не надо поднимать api или писать консольное приложение, достаточно написать один тест. Заманчиво ?
Окей
На примере наших методов вызова api. Что нужно чтобы написать тест ?
Добавляем новую библиотеку в проект. Я для простоты все делю на уровни (папки в решении) эту тему я также раскрою в отдельной статье выглядит это так
Data.Gpt - это наша библиотека, которую мы хотим протестировать
Test.Gpt - это наша библиотека, в которой мы будем писать тесты
Чтобы тестовая библиотека стала реально тестовой библиотекой нужно установить две зависимости из nuget
xUnit - это фреймворк для тестирования есть еще множество других например NUnit или MSTest. Но xUnit самый модный.
Microsoft.NET.Test.Sdk - это sdk для запуска тестов из среды разработки
Добавляем файл GptRepositoryTests.cs - здесь мы опишем наши сценарии для тестирования
Сценарий это по сути метод отмеченный флагом [Fact] это сигнал о том, что этот метод - это тест.
Называть эти методы можно по разному и не стоит бояться, что название будет на весь экран. Название теста должно говорить само за себя. Я называю так. Какой объект тестируем, какой метод и какой ожидаемый результат. Объект это GptRepository, метод это GetCompletions и результат, что результат метода не null.
Пометка! Я переименовал метод, но не переименовал тест - не хорошо. Правильно назвать GptRepository_GetCompletions_NotNull. Спасибо
Обратим внимание на несколько строк.
13 - мы создаем эксземпляр нашего класса
15 - вызываем наш метод и получаем результат
35 - проверяем, что результат не null
В этом же файле пишем тест для второго метода он не отличается от первого не будем на это останавливаться
Теперь запускаем наши тесты. В качестве среды разработки я использую JetBrains Rider, но в MS Visual Studio все в целом также. В нижней части есть вкладка с тестами и мы их просто запускам.
Важно! Если тесты просто запустить, а не запустить в режиме Debug, то брейкпоинты работать не будут.
Кажется все окей и наша библиотека - рабочая.
Важно! Круто написать пару тестов, но как только это стало привычкой следующий этап это покрыть весь код тестами. Помимо наших двух можно добавить тест, что получить ошибку 401 или 402 и тд. Покрытие считается в процентах. Если покрытие кода 80% - это очень хороший результат. 100% не будет никогда.
В этой статье мы проверили наши методы на адекватность и немного коснулись темы тестирования. Теперь осталось понять, есть ли разница между WebRequest и HttpClient для этого мы их измерим с помощью бенчмарков. И решим есть ли смысл переходить с устаревшего подхода на не устаревший.
Увидимся в следующей статье! Пишите вопросы в комментариях.