Юнит-тестирование это про разделение функций на минимально возможные кусочки, чтобы их было возможно протестировать минимально возможным тестом. А для этого каждая функция должна делать что-то одно. У вас же функция занимается следующими вещами:
- Ведет диалог с пользователем
- Проверяет корректность введенных данных по своим правилам
- Обращается к внешнему сервису (причем какой-то апи-ключ прямо в коде - ужас-ужас. А если этот код выкладывать в гитхаб?)
- Выводит полученный от внешнего сервиса результат на экран
Разделим это на 4 функции и увидим следующее:
- Функция ввода номера пользователем. Входных параметров нет, выходные - номер. Тестировать не имеет особого смысла.
- Функция валидации. Входной параметр - номер, выходной - один из кодов (enum): все хорошо, некорректный регион, некорректный номер. Функция чистая (то есть результат её работы зависит только от аргумента, побочных эффектов нет), тестами накрывается легко и просто.
- Функция запроса данных у стороннего сервиса. Входной параметр - номер, выходной - какие-то данные. Тестировать сложно т.к. есть внешний сервис. И может быть не особо нужно, т.к. юнит-тест тут не напишешь. Функция как-то сложной логики не имеет, а внешний сервис нам неподконтролен. В частности, он в любой момент может начать отвечать 404 или каким-нибудь бредом. Поэтому тестировать эту функцию мы можем только имитируя поведение внешнего сервиса каким-то нашим моком (использовать тот же WireMock, например)
- Функция вывода результата на экран. Входной параметр - данные, выходных нет. Аналогично функции ввода номера тестировать отдельно не имеет смысла.
Таким образом, вся бизнес-логика программы сосредоточена в функции валидации и внешнем сервисе. Внешний сервис, как я уже сказал, нам неподконтролен. Функцию валидации мы можем накрыть юнит-тестом. Остальное - если хочется, то можно накрыть end-to-end тестом, либо не покрывать вообще.
