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

Скепсис про «GUI не тестируется» держится на путанице двух вещей: событий экрана и событий приложения. В Fyne клик — это вызов метода Tapped у виджета, нажатие клавиши — вызов TypedRune, и настоящий монитор нужен только чтобы превратить движение мыши в этот вызов. Тестовый пакет делает последний шаг сам: события подсовываются виджетам напрямую, и вся логика — обработчики из шестого урока, валидаторы из восемнадцатого, привязки из семнадцатого — выполняется в обычном go test без единого окна. Запрос «fyne тесты» — это три слоя проверок. Первый — чистая логика: хранилища задач и подсчёты тестируются как обычный Go, им интерфейс не нужен вовсе. Второй — поведение: после test.Tap по кнопке состояние изменилось, после test.Type в поле валидатор выдал ошибку. Третий — отрисовка: снимок разметки ловит случай, когда кнопка осталась кликабельной, но исчезла с экрана из-за ошибки раскладки. Правило проекта: логику держи вне виджетов — тогда первый слой покрывает большую часть кода, а UI-тесты добивают стыки. Главный запрет урока: в тестах не должно быть app.New() — он просит у операционной системы настоящий драйвер, и на машине без экрана сборка упадёт. Для всего этого есть test.NewApp, о нём дальше.

Каждый тест начинается с test.NewApp() — и это не замена одной строчки, а смена среды. Приложение создаётся с тестовым драйвером: окна не открываются, рендер идёт на невидимый холст, а всё персистентное — настройки из девятнадцатого урока и хранилище из двадцать первого — живёт в памяти и умирает с тестом. Именно поэтому тесты с preferences не трогают твой настоящий файл настроек: тест изменил ключ, закончился, и мир чист. Из этого следует правило гигиены: один test.NewApp на одну тест-функцию. Общее состояние между тестами — источник самых загадочных сбоев: тест прошёл один, упал в паре с соседним, а по отдельности оба зелёные. Тестовое окно создаётся через test.NewWindow(содержимое): оно разворачивает виджеты на невидимом холсте, применяет раскладку и измеряет размеры — без него проверки, зависящие от MinSize и позиций, не имеют смысла. Окно нужно и для событий, требующих холста: прокрутка и перетаскивание идут через canvas. Для темы есть test.ApplyTheme — подменить тему на время теста и проверить, что тёмный вариант из пятнадцатого урока не сломал контраст. И тонкость порядка: создавай виджеты после test.NewApp — часть инициализации виджетов читает тему приложения, и без тестового приложения она падает или берёт мусор. Среда готова — теперь в неё можно пустить пользователя.

Пакет test покрывает все виды взаимодействий, которые ты учил в шестом уроке. Клик: test.Tap(obj) для левой кнопки по любому Tappable — кнопки, элементы списка из десятого урока; test.TapSecondary(obj) для правого — так открываются контекстные меню из четырнадцатого; test.TapAt(obj, pos) целится в конкретную точку виджета; test.DoubleTap(obj) для двойного нажатия. Ввод: test.Type(obj, строка) для Focusable-объектов — полей ввода и всего, что принимает клавиатуру; функция сама даёт фокус, поэтому порядок «сначала Type, потом проверки» работает без ритуалов. Прокрутка и жесты: test.Scroll(canvas, pos, dx, dy) крутит Scrollable-контейнеры, test.Drag(canvas, pos, dx, dy) тянет перетаскиваемые элементы — так проверяются списки с drag-реордером. Движение мыши без клика — test.MoveMouse. Важно понимать механику: это не эмуляция операционной системы с курсором и задержками, а прямой вызов событий на объекте. Отсюда скорость — сотни тестов за секунды — и две границы. Первая: реальную раскладку окна и попадание в координаты тест не проверяет — если кнопка перекрыта другим виджетом, test.Tap по ней всё равно сработает, и это ловит снимок разметки, а не клик. Вторая: асинхронное поведение из двадцатого урока — код, запущенный через fyne.Do, исполняется не мгновенно, и тест должен дождаться завершения, а не спать вслепую. В остальном арсенал покрывает всё, что делает палец.

Клик и ввод проверяют поведение, но не внешний вид: кнопка может потерять иконку, метка — съехать, контейнер — схлопнуться, и все тесты останутся зелёными. Для этого слоя есть снимки. test.AssertRendersToMarkup(t, «greeting.xml», w.Canvas()) разворачивает дерево объектов в текстовую разметку — структуру, типы виджетов, тексты, — и сравнивает с золотым файлом в каталоге testdata; файл не совпал — тест красный, и diff показывает ровно ту строку, которая изменилась. Сестринский test.AssertRendersToImage сравнивает целую картинку отрисовки, но у изображения есть врождённая болезнь: сглаживание и шрифты чуть-чуть отличаются между платформами, и снимок с ноутбука не сходится со снимком с CI. Поэтому бытовое правило — по умолчанию markup-снимок, image-снимок только когда проверяется именно пиксельная графика из седьмого урока. Быстрая проверка без каталога testdata: test.RenderToMarkup(canvas) возвращает строку разметки, и её можно сравнить в тесте напрямую или напечатать при отладке. Когда снимок красный, у тебя два честных исхода: регрессия — чини код, и осознанное изменение дизайна — обнови золотой файл и упомяни это в коммите. Не обновляй снимки машинально: золотой файл — это договор о том, как выглядит приложение, и его правка должна быть решением, а не привычкой. Меняешь тему из пятнадцатого урока — снимки честно покраснеют и заставят перечитать, что именно поменялось.

Тестирование fyne — это ещё и умение подменять мир вокруг интерфейса. Первый мок уже встроен: test.NewApp даёт настройки и хранилище в памяти, поэтому код, читающий preferences из девятнадцатого урока, тестируется без диска — установи ключи в начале теста и проверь, как экран их подхватывает. Второй слой — собственные фейки для данных: если список из десятого урока питается из интерфейса Store, тест подсовывает реализацию с фиксированным срезом — и проверяет, что List показал ровно их и вызвал шаблон нужное число раз. Отсюда и архитектурная награда разделения: чем тоньше слой виджетов, тем меньше UI-тестов нужно. Третий инструмент — рендерер кастомных виджетов из восьмого урока: test.WidgetRenderer(wid) возвращает WidgetRenderer, и тест может проверить объекты напрямую — сколько их, каких типов, с какими цветами. Это точечная проверка внутренностей без снимков: полезно для своих контролов, где разметка длинная и шумная. Четвёртая подмена — время и темы: test.ApplyTheme подставляет тему, а test.NewTheme собирает тестовую; если твой виджет берёт цвета из темы, подмена доказывает, что хардкода нет. Правило отбора моков простое: подменяй границы — диск, сеть, время, — но не подменяй виджеты, которые тестируешь: тест, в котором кнопка — мок, проверяет только твой оптимизм. Фальшивое хранилище — да, фальшивая кнопка — нет.

Соберём пирамиду для реального приложения. Основание — чистые структуры: хранилище задач финального проекта тестируется без единого виджета — добавил, отметил, удалил, сохранил, перечитал; таблица тестов Go покрывает граничные случаи дешевле любых UI-симуляций. Средний слой — валидация и связки: валидатор из восемнадцатого урока проверяется прямым вызовом Validate, привязки из семнадцатого — чтением источника после Set. Вершина — UI-тесты: по одному на пользовательский сценарий, не на каждый виджет — «ввёл текст, нажал добавить, задача появилась в списке и в хранилище», «правый клик по задаче открывает меню удаления», «закрытие с несохранённым спрашивает подтверждение» из двадцать третьего урока. На эту вершину вешаются markup-снимки ключевых экранов — по одному на состояние: пустой список, список с задачами, экран настроек. Итоговая пропорция зрелого проекта: десятки тестов логики, несколько поведенческих UI-тестов, пара снимков на экран. Если всё наоборот — тысячи кликов и ни одной проверки хранилища — тесты будут медленными и хрупкими. Прогони готовый проект по этой пирамиде в двадцать пятом уроке: там каждая функция итогового приложения уже расчищена под тест именно так.

Теперь у курса есть система контроля качества: логика проверяется чистыми тестами, поведение — симулированным пользователем, отрисовка — снимками, а моки закрывают доступ к настоящему диску. Опора урока — третий урок с виджетами, восьмой с рендерерами, десятый со списками, девятнадцатый с хранением и двадцать третий с поведением окна, которое тоже теперь под тестом. Финальная тема — итоговый проект: менеджер задач, который собирает все двадцать четыре урока в одно приложение, от модели данных до темы, и живёт на диске между запусками. Полный маршрут — на странице курса Fyne.