Тестирование команд CLI

Execute без подготовки читает os.Args — это поведение продакшена. rootCmd.SetArgs([]string{"list", "--limit", "5"}) подменяет его: Cobra разберёт этот срез, как будто пришёл из шелла. Вывод уходит туда, куда указывает rootCmd.SetOut(writer): передайте &bytes.Buffer{}, и всё, что команды печатают через cmd.OutOrStdout(), окажется в буфере. Аналогично SetErr ловит сообщения об ошибках и usage при неудачном парсинге — это важно, потому что при ошибке Cobra пишет в stderr, и без SetErr она бы попала в вывод самого go test. Читается буфер после Execute: got := buf.String(), дальше strings.Contains или точное сравнение через strings.TrimSpace. Комбинация SetArgs плюс SetOut плюс Execute плюс assertion — весь каркас тестирования cobra; остальное — дисциплина: тест должен видеть свежую команду, а не глобальную, измученную предыдущими тестами. Про это — следующий блок, это самая частая ошибка в тестах CLI.

Глобальная rootCmd — минное поле для тестов: значения флагов в pflag персистентны между вызовами Execute, и тест, поставивший --limit 5, оставит его следующему; в списке команд и переменных пакета то же самое. Решение стандартное для CLI на Cobra — фабрика: newRootCmd() создаёт корень, добавляет подкоманды и возвращает всё целиком. main вызывает её один раз, каждый тест — заново, и тесты перестают влиять друг на друга. Вместе с фабрикой заводится хелпер runCmd(args ...string), который собирает команду, подставляет буферы, исполняет и возвращает вывод с ошибкой: тело теста сжимается до трёх строк. На больших проектах фабрика принимает структуру зависимостей — путь к хранилищу, тайминг — и тесты подсовывают временный каталог вместо реального хранилища; к тому, как раскладывать такие зависимости по пакетам, вернёмся в уроке про структуру проекта.

У CLI набор сценариев повторяется: корректные аргументы, нехватка аргументов, неизвестный флаг, отказ пользователя — и на каждый хочется одинаковых проверок. Табличные тесты складывают сценарии в срез структур и гоняют один цикл: имя кейса, args, wantErr, wantOut. Отдельное поле wantErr — не только bool, но и подстрока ошибки: текст ошибки — часть контракта команды, потому что его видит пользователь. t.Run даёт имена кейсам в выводе и запускает только нужный через -run с именем кейса. Табличная форма дисциплинирует и другое: когда сценарий виден списком, легко заметить, что непокрытых веток стало больше, чем кажется, — скажем, --limit 0 и --limit -1 живут в одной таблице рядом. Внутри кейса используются тот же runCmd и те же assertions из первого теста — каркас не меняется, растёт только таблица.

Код выхода CLI рождается из ошибки RunE: main получает её от Execute и вызывает os.Exit(1) — схема из урока про ошибки и коды выхода. В тесте процесс не выходит, зато возвращается та самая ошибка, и это удобнее, чем код: ошибка типизируется. Сентинелы вроде errDeclined сравниваются через errors.Is — тест отличает честный отказ пользователя от сбоя хранилища, хотя оба дают код 1. Для многослойных ошибок с fmt.Errorf и %w проверяется подстрока через err.Error() или errors.Is по корневому сентинелу. Отдельно протестируйте ветку, где команда падает на валидации данных, а не на парсинге: непарсируемый JSON в хранилище должен дать внятную ошибку, а не панику. Помните про SilenceUsage: с ним usage не печатается на каждую ошибку RunE, и буфер stderr в тестах остаётся для реальных сообщений.

Точный вывод большой таблицы или JSON в Contains не вставишь: строк много, формат живой. Решение — golden-файлы: эталонный вывод лежит в testdata/*.golden, тест сравнивает буфер с файлом побайтно, а при запуске с флагом -update записывает свежий вывод на место эталона. Это быстро строится поверх того же каркаса: runCmd вернул строку — сравнили с golden. Ловушки две: нестабильные данные — даты, абсолютные пути, порядок ключей карт — попадают в эталон и ломают тест на другой машине; вычищайте их перед сравнением или подставляйте фиксированные значения. И дисциплина обновления: -update запускается осознанно, а дифф golden-файла читается в ревью как настоящая правка пользовательского вывода. Хелперы для сравнения уже написаны: библиотека github.com/sebdah/goldie сама кладёт эталон в testdata/golden и поддерживает тот же флаг -update; в маленьких проектах хватает и ручных пяти строк поверх os.WriteFile. Полный конвейер прогоняется локально: go test ./... — песочница тестовый раннер не эмулирует, здесь нужен живой Go с модулями проекта.

Тесты — последний навык до финала курса: в итоговом проекте менеджер задач снабжён табличными тестами на add и list, а структура большого проекта покажет, где лежат testdata и фабрики команд в реальном репозитории. Приёмы тестирования переносятся и на веб: табличные тесты и буферы в тестировании Gin выглядят почти так же. Обзор курса — на странице Cobra. Практика: переведите свою утилиту на фабрику newRootCmd, напишите runCmd и табличный тест на три сценария одной команды, затем проверьте сентинел отказа через errors.Is.