Если вы пишете тесты на ZIO, то с моками, скорее всего, уже сталкивались. И почти наверняка — с ZIO Mock. Формально он решает задачу, но на практике ломает Arrange‑Act‑Assert, «краснит» в IDEA и иногда падает так, что вы видите только InvalidCallException: null. В Яндекс Вертикалях мы довольно долго жили с этой библиотекой — пока количество таких тестов не перевалило за пару сотен и они не расползлись по десятку команд.

Меня зовут Женя Веретенников, я тимлид в Яндекс Вертикалях и последние годы занимаюсь инструментами для Scala‑разработчиков и инфраструктурой бэкенд‑монорепозитория. Когда стало ясно, что ZIO Mock больше мешает, чем помогает, мы решили отказаться от него полностью — и подружить ZIO Test с классическим ScalaMock. Он даёт более предсказуемый синтаксис и понятные ошибки, но из коробки с ZIO не работает.

В этой статье я расскажу не о том, как пользоваться новой библиотекой, а о том, как мы её делали: какие ограничения ZIO‑стека пришлось учитывать, где пришлось лезть под капот ScalaMock и ZIO Test и во что в итоге превратилась эта инженерная затея. Это история про построение собственного test tooling в большой Scala‑кодовой базе — с честными компромиссами и практическими выводами.

В процессе поддержки различных проектов я несколько раз попадал в ситуацию, при которой по причине неправильной работы с Promise возникали проблемы на продакшне. Причём паттерн этой самой неправильной работы всегда был один и тот же, но скрывался он в разных обличьях. Более того, ошибочный код был написан различными людьми. К тому же, ни в одной статье по работе с Promise я толком не нашёл упоминание проблемы, которую хочу осветить. Так что предполагаю, что многие забывают про проблему, про которую я расскажу.

Интересно почитать много примеров асинхронного кода на Scala, с промисами, фьючами и акторами? Добро пожаловать под кат!