Тесты фоновых задач: asynq на Redis

Тесты фоновых задач go делятся на три слоя, и нагрузка распределена между ними неравномерно. Первый слой — юнит: хендлер вызывается напрямую ProcessTask с context.Background(), без Redis, за микросекунды; зависимости подставляются интерфейсами и стабами. Второй слой — постановка: настоящий клиент кладёт задачу в живой Redis, а Inspector подтверждает эффект — состояние, очередь, отложенный срок. Третий слой — сквозной: воркер с ServeMux забирает задачу и доводит её до хендлера, проверяя маршрутизацию и согласованность конфигов. Ключевое отличие от привычной пирамиды: второму и третьему слою нужна инфраструктура, поэтому пишут их мало — по одному тесту на каждый шаблон постановки и один-два на саму доставку. Юнит-слоя может быть сколько угодно, он бесплатный. Перекос в любую сторону врёт: только юниты пропускают ошибки конфигурации очередей, а только интеграционные тесты делают набор медленным и хрупким. Дисциплина в том, чтобы каждый уровень получал свои утверждения: перетаскивание проверок вверх или вниз только путает диагностику.

Тест постановки отвечает на вопрос «задача вообще легла в очередь?». Механика простая: asynq.NewClient строится на адрес контейнера — тот же RedisClientOpt, что и боевой, отличается только Addr. Enqueue возвращает TaskInfo с идентификатором — он и становится ключом проверки. Дальше включается Inspector: NewInspector на тот же адрес, GetTaskInfo(queue, id) — и у теста в руках полное досье: State, Retried, LastErr, NextProcessAt. Немедленная постановка лежит в состоянии pending, ProcessIn переводит её в scheduled с расчётным сроком — оба утверждения записываются сравнением State с TaskStatePending и TaskStateScheduled. Проверка честная: она проходит через весь код постановки asynq, включая разбор опций и раскладку по ключам Redis, а не подглядывает в internals. Ошибку Enqueue проверяйте обязательно: клиент не подключается в конструкторе, и первая настоящая сетевая ошибка вернётся именно здесь — тест упадёт с ясной причиной, а не зависнет. Inspector при этом живёт независимо от воркеров: он читает Redis сам, поэтому постановку можно проверять, пока ни один воркер ещё не поднят, — и это правильный порядок: сначала очередь, потом доставка.

Постановка — половина контракта; вторая половина — что воркер дойдёт до хендлера. Прямой вызов ProcessTask маршрутизацию не проверяет: она живёт в ServeMux и конфиге сервера. Интеграционный тест поднимает настоящий asynq.NewServer на адресе контейнера: NewServeMux, регистрация хендлера по типу задачи, srv.Run(mux) в горутине. Хендлер в тесте сигналит о доставке — обычно каналом, в который пишет факт вызова и ошибку. Тест ставит задачу, ждёт сигнал через select с таймаутом и утверждает результат. Такой тест ловит то, что не увидит ни один юнит: опечатку в типе задачи между клиентом и mux, очередь, не включённую в Queues конфига, хендлер, забытый при рефакторинге. Цена — секунды на прогон и живая горутина воркера, которую нужно аккуратно остановить Shutdown-ом в Cleanup. Параллельность здесь тоже честная: Concurrency в конфиге задаёт число горутин-обработчиков, и для теста хватает единиц — скорость доставки от этого не страдает, а нагрузка на машину минимальна. Меньше одного сквозного теста на пакет не стоит: он единственный проверяет, что клиент и воркер вообще договорились.

Redis в контейнере — общий на пакет, а тесты должны оставаться независимыми. Первый инструмент — уникальные имена очередей: asynq.Queue(queue) при постановке, где queue выводится из t.Name() или пишется константой конкретного теста. Задачи не перемешиваются: у каждой тестовой очереди свой набор ключей в Redis, asynq хранит очереди раздельно. Обратная сторона: воркер обрабатывает только очереди из Config.Queues — карту «имя: вес» собирают под конкретный тест, иначе задачи зависнут в pending навечно, и никакая ошибка об этом не скажет. Второй инструмент — логическая база Redis: поле DB в RedisClientOpt разводит тесты по разным пространствам ключей, но рядом с уникальными очередями это избыточно. Третий — чистка между тестами: FlushDB стирает всё, включая чужие данные, поэтому безопасен только при строгой сериализации прогона. На практике хватает первого инструмента: уникальная очередь на тест плюс ровно она в Queues — и параллельность изоляции не мешает. Имена с slug'ом теста удобнее формировать хелпером: один вызов — и каждая проверка получила собственное пространство задач без дублей.

Границу слоёв удобно держать в голове как таблицу: что проверяем — чем проверяем. Юнит-тесты отвечают за логику хендлера и взаимодействия через интерфейсы: они не знают ни Redis, ни Docker и гоняются при каждом сохранении файлов. Интеграционные — за контракт с очередью: постановку, опции, состояние, маршрутизацию, согласованность конфигов. Это деление не вкусовщина, а экономика: поднять Redis в контейнере — секунды, и на каждой такой проверке прогон растёт; в то же время ошибку «поставили задачу не в ту очередь» юнит-тест не поймает в принципе, как и не поймает рассинхрон Queues между постановкой и воркером. Мок врёт ровно там, где начинается библиотека: у стаба нет состояний pending и scheduled, нет ретраев и нет досье по ID. Поэтому моки оставляют хендлеру и его зависимостям, а очередь проверяют живой — настоящим клиентом против настоящего Redis в контейнере. Отсюда практический вывод: сколько бы ни было хендлеров, интеграционных тестов постановки обычно три-четыре — немедленная, отложенная, идемпотентная с фиксированным TaskID и одна на ошибку постановки.