Тестирование обработчиков

asynq.Handler — это интерфейс с одним методом ProcessTask(ctx context.Context, t *asynq.Task) error, а asynq.HandlerFunc — адаптер для функций. Отсюда главный приём: тест создаёт задачу через asynq.NewTask(type, payload) и вызывает хендлер напрямую с context.Background() — Redis, сервер и очередь не нужны, тест выполняется за микросекунды. Внутри теста задача неотличима от боевой: t.Type() вернёт имя типа, t.Payload() — байты payload, так что хендлер распакует JSON ровно так же, как в продакшене. Если хендлер — метод структуры, тестируется метод: HandleCapture{}.ProcessTask(ctx, task). Что такой тест проверяет: разбор payload, бизнес-логику, возвращаемую ошибку. Что не проверяет: постановку, опции, ретраи и время — это ответственность других слоёв, и смешивать их в один тест не стоит. Отдельный маленький контракт: хендлер обязан уважать контекст, и это тоже тестируется без asynq — передайте контекст с отменой и убедитесь, что функция вернулась, а не уснула до конца работы. Приём масштабируется и на контекст из семнадцатого урока: если хендлер читает из ctx значения, тест кладёт их туда теми же хелперами — сигнатура вызова не меняется, меняется только подставленный контекст.

Половина поломок задач — не в логике хендлера, а в payload: забытое поле, поменянный тег JSON, вложенная структура с указателем. Ловить это интеграционным тестом — дорого, ловить нечем вообще, если сборка размазана по хендлерам. Практика: функция сборки payload — отдельная тестируемая единица. Например, BuildPaymentPayload(order Order) ([]byte, error) сериализует структуру и проверяется таблично: какие поля попадают в JSON при нулевых значениях, что происходит с датами в нестандартных таймзонах, какая ошибка возвращается на невалидном заказе. Хендлер тогда тестируется на готовых []byte — фиксация payload прямо в тесте, в читаемом виде, становится документацией формата: апгрейд формата ломает тест раньше, чем живые очереди. Обратная сторона: не тестируйте json.Marshal сам по себе — тестируйте свою структуру и её теги; стандартная библиотека уже покрыта её собственными тестами, а ваши теги — нет. Отдельно проверяйте нулевые значения: JSON не различает пустую строку и отсутствие поля, и именно на нулях форматы ломаются чаще всего. Держите сборку рядом с типом payload в одном файле: правка структуры и правка теста едут одним коммитом, и рассинхрон между продакшеном и тестом становится невозможным.

Хендлер, который пишет письма и списывает деньги, тестируется как любой другой код с зависимостями: зависимости объявляются интерфейсами, а в тест подставляются стабы. Struct-хендлер из семнадцатого урока для этого идеален: HandleWelcome{Mail Mailer} — где Mailer — интерфейс с методом Send. В тесте Mailer заменяется структурой-стабом, которая запоминает вызовы: сколько раз позвали Send, с каким адресом и темой, вернула ли ошибку. Проверки становятся содержательными: после удачного ProcessTask стаб получил один вызов с правильным адресом; после ошибки SMTP-стаба хендлер вернул ошибку — и задача уйдёт в retry по политике; после битого payload хендлер обернул ошибку в SkipRetry. Тот же приём работает для Wallet: стаб-кошелёк с управляемым балансом покрывает сценарии «денег хватило» и «недостаточно средств» без единого реального счёта. Важно, что интерфейсы объявляет ваш код, а не asynq: очередь здесь ни при чём, это обычный юнит-тест Go, и пишется он теми же table-driven конструкциями, что и весь ваш код. Вторая польза стабов — скорость: хендлер, который в бою ждёт SMTP секунды, в тесте отрабатывает за микросекунды, поэтому весь набор гоняется на каждый коммит, а не ночью по расписанию.

Слой постановки тоже заслуживает теста: правильно ли собраны опции, попадает ли задача в нужную очередь, корректен ли scheduled-срок. Здесь без Redis не обойтись, но настоящий не нужен: miniredis поднимает Redis-сервер в памяти прямо внутри тестового процесса. Схема теста: mr := miniredis.RunT(t), затем клиент asynq.NewClient(asynq.RedisClientOpt{Addr: mr.Addr()}) — и Enqueue против него. Проверка результата — через Inspector из пятнадцатого урока, построенный на тот же адрес: GetTaskInfo(queue, info.ID) вернёт TaskInfo, у которого утверждается State и NextProcessAt. Это честная проверка: она проходит через настоящий код постановки asynq, включая scheduled-состояния и TaskID-конфликты, — а не через подглядывание в internals. О честности стоит сказать прямо: публичного пакета тест-хелперов у asynq нет — инструменты, которыми пользуются тесты самой библиотеки, живут в internal/testutil и internal/testbroker, брокер целиком в памяти, и извне не импортируются. Изоляция — вторая награда: тест, упавший против общего Redis, может испортить чужой прогон, а тест против своей копии в памяти не умеет мешать соседям даже при параллельном запуске. Практический минимум поэтому прост: miniredis, настоящий Client и Inspector — этого хватает на весь интеграционный слой. Сколько таких тестов нужно: по одному на каждый шаблон постановки — немедленная, отложенная, идемпотентная с TaskID; три-четыре теста закрывают почти любой сервис, и каждый выполняется за десятки миллисекунд.

Всё, что зависит от времени, тестируется подстановкой времени, а не ожиданием. Минимальный clock-интерфейс — это поле now func() time.Time: боевой код получает его значением time.Now, тест — константой. Так проверяются расчёты «окно списания — первые числа месяца», дедлайны из одиннадцатого урока и логика «повторная попытка не раньше, чем через час». Для хендлеров, живущих в контексте, работает и второй приём: тест передаёт контекст с context.WithDeadline(ctx, fixedTime) — код, уважающий дедлайн, отработает одинаково в любой день года. Отдельно про scheduled-задачи: ProcessIn и ProcessAt в тесте постановки проверяются через NextProcessAt из TaskInfo — это время, вычисленное asynq от настоящего clock, поэтому утверждать стоит интервал «примерно тридцать минут от старта теста», а не равенство до секунды; проверки равенства добейтесь в своей логике, где время инжектится, а не в библиотеке, где время живёт. Приём работает и для повторов: собственная RetryDelayFunc из тринадцатого урока — чистая функция от счётчика попыток и ошибки, и тестируется она отдельно, без Redis: фиксированные попытки на входе, интервалы на выходе.