Тестирование TUI-приложений

Схема Model-Update-View делает приложение тестируемым по построению: Update — переход из состояния в состояние по сообщению, и его можно вызвать руками, собрав сообщение как обычное значение. tea.KeyMsg{Type: tea.KeyTab} — не эмуляция клавиатуры, а тот же тип, которым фреймворк сообщает о нажатии; нет никакой разницы, откуда он пришёл. Тест собирает модель конструктором, зовёт Update, приводит результат к своему типу и сравнивает поля. View — тоже просто строка: присвоили статус, вызвали View, проверили содержимое. Такой тест проходит за миллисекунды, не открывает терминал и не зависит от шрифтов и ширины окна — его можно гонять в CI без единой настройки. Главная дисциплина — проверять свои решения, а не чужой код: то, что Tab двигает курсор textinput, отвечает библиотека bubbles; ваше обязательство — что ветка вызвала Blur, сдвинула индекс и вернула команду. Граница проходит там же, где и граница ответственности в восьмом уроке про подмодели.

Переходы состояний — самое ценное: флаги, индексы, статусы, границы цикла фокуса. Именно они ломаются тихо и именно их дёшево проверить. View проверяется иначе: не полным равенством строки, а поиском подстрок. Причина практическая: рамки, отступы и цвета из Lip Gloss меняются от правки к правке, и тест, сравнивающий весь экран целиком, краснеет при каждом косметическом коммите — через неделю его удаляют, и это худший финал для набора тестов. Contains по ключевым словам — «логин не может быть пустым», номер выбранной задачи, отформатированное время — стабилен и всё ещё ловит исчезнувший с экрана статус. Отдельно про чужой код: не тестируйте textinput и list — у Charm свои тесты; ваш тест ловит то, что вы забыли переслать сообщение или потеряли команду. И держите тесты на неудобные места: двойной Enter, Shift+Tab с первого поля, пустая валидация — баги живут там, где рука не доходит при ручной проверке. Прогон с -race сверху добавит ловлю гонок бесплатно: команды живут в горутинах фреймворка, и модель, тронутая из чужой горутины, краснеет в тесте раньше, чем в проде.

Чистые тесты не отвечают на вопросы про программу целиком: дошёл ли Batch из двух команд до рантайма, отработает ли цепочка тиков, не зациклится ли Update при определённом порядке сообщений. Для этого у Bubble Tea есть собственный пакет teatest — он импортируется как github.com/charmbracelet/bubbletea/teatest. teatest.NewTestModel запускает настоящую tea.Program в фоне, с фиксированным размером терминала через WithInitialTermSize, и возвращает обёртку TestModel. Ей отправляют сообщения через tm.Send — и клавиши, и свои типы; набор текста передаётся рунами: tea.KeyMsg{Type: tea.KeyRunes, Runes: []rune("анна")} — то же сообщение, что приходит от настоящей клавиатуры, включая русские буквы. Читают вывод через tm.Output(); ждут появления подстроки функцией teatest.WaitFor с таймаутом teatest.WithDuration. Завершение — tm.Quit и tm.WaitFinished; для снимков всего кадра есть tm.FinalOutput. Разница с чистым тестом принципиальная: здесь работает настоящий цикл событий, команды возвращаются по-настоящему, порядок сообщений такой, каким он будет у пользователя. Цена — миллисекунды реального времени и осторожность с таймаутами: медленная машина не должна ронять тест.

Часы из предыдущего урока тестируются без единой секунды ожидания, и причина — чистота Update: tickMsg со временем это обычное сообщение, ничем не лучше клавиши. Тест собирает момент руками — time.Date(2025, 3, 1, 9, 41, 0, 0, time.UTC), отправляет в Update и проверяет, что View показывает 09:41:00. Никаких спящих тестов: то, что заняло бы секунду реального времени, здесь ноль миллисекунд и полный детерминизм. Дедлайны проверяются тем же ходом: отправьте timeoutMsg{gen: m.gen} руками и убедитесь, что экран ушёл в ошибку; отправьте timeoutMsg{gen: m.gen - 1} — и убедитесь, что данные устояли, метка принадлежности сработала. Деградацию частоты проверяет чистая функция interval(): состояние — интервал, табличный тест на три режима, терминал не нужен. Вот почему время в сообщении из урока двадцать один — не украшение: без него фиктивное время было бы невозможно, а тесты часов — только спящими.

Остался последний барьер — команды, которые ходят в сеть. Чистый тест вызывает Update, ветка Enter честно возвращает submitFormCmd, и запрос уходит из теста наружу. Лечение — зависимость вместо прямого вызова: у модели поле submit func(login, pass string) tea.Cmd, продакшен присваивает ему настоящую фабрику при старте в main, тест — подмену, которая возвращает замыкание с готовым сообщением submitDoneMsg. Зависимость и проверяется: фейковая функция ставит флаг called, тест утверждает, что Enter её дёрнул, и при желании — что аргументы дошли из Value полей: сохраните login и pass в замыкании фейка и сравните с ожидаемыми. Тот же ход работает для загрузки из девятнадцатого урока: фабрику fetchItemsCmd несут полем и подменяют фиктивным ответом. И про масштаб: подмодели из восьмого урока тестируются отдельно от корня — экран списка получает свои сообщения без роутинга, корень проверяет только пересылку. Если Update невозможно протестировать без сети и терминала, это диагноз: IO попал не в команду, а в Update.

Тесты — зеркало архитектуры: где их не получается написать, там слоя намешаны. Следующий урок про структуру проекта разложит код по пакетам так, чтобы домен тестировался без tea, экраны — без корня, а корень — без сети. Моки команд отсюда переезжают туда без правок, как и подмена загрузки из урока про HTTP. Если писали десктопные приложения на Fyne, сравните подходы: там тесты виджетов требуют test.NewApp и рантайма интерфейса — тестирование fyne — а здесь терминал и вовсе не нужен, и это честное преимущество Elm-архитектуры. Обзор курса — на странице Bubble Tea. Прогон — локальный go test ./..., ни терминала, ни песочницы не требуется. Практика: закройте форму табличными тестами на все ветки — Tab, Shift+Tab с краёв, двойной Enter, пустой логин — и убедитесь, что ни один не спит.