В Foundry 1.8.0 добавили мощные режимы тестирования для Solidity‑проектов: символическое выполнение через локальный решатель, mutation‑тесты и стресс‑проверки памяти. Плюс — заметные изменения по умолчанию, из‑за которых тесты после обновления могут внезапно начать падать.
Foundry — один из самых популярных наборов инструментов для разработки смарт‑контрактов на Solidity. В версии 1.8.0 команда сделала акцент на качестве тестирования и безопасности: появились новые режимы проверок, а некоторые настройки по умолчанию стали «строже», чтобы тесты больше походили на поведение в реальной сети.
Что изменилось в тестировании
Главные новшества релиза — это способы находить ошибки раньше и надёжнее, даже если код уже покрыт тестами.
Символическое выполнение тестов (через локальный SMT‑решатель)
В Foundry появился режим символических вычислений: инструмент пытается не просто перебрать случайные входные данные (как фаззинг), а «логически» искать такие значения, при которых контракт ведёт себя неправильно. По задумке это приближает разработку к более практичной формальной верификации, но без необходимости переписывать сам контракт под отдельный инструмент.
Как включается: запуск тестов с флагом --symbolic, например forge test --symbolic.
Почему это важно: ошибки, которые сложно поймать случайным перебором, иногда находятся именно такими методами — особенно в местах, где много ветвлений и условий.
Mutation‑тестирование: проверка «не для галочки»
Обычное покрытие строк кода легко вводит в заблуждение: тест может выполняться, но не проверять смысл. Mutation‑подход работает иначе: инструмент делает небольшие изменения в коде (условно «ломает» его) и смотрит, замечают ли это тесты.
Как включается: forge test --mutation.
Практический эффект: полезно для критичных модулей (права доступа, расчёт комиссий, лимиты, логика ликвидаций). Если мутации «выживают», значит, тесты не ловят важные отклонения.
Brutalize‑режим: тесты с «грязной» памятью
Ещё один режим помогает отлавливать ошибки, которые проявляются при нестандартных состояниях памяти: перед запуском тестов некоторые области могут быть заполнены случайными значениями.
Как включается: forge test --brutalize.
Зачем обычным командам: это снижает шанс пропустить баги, которые возникают только при редких комбинациях состояний или после цепочки вызовов.
Улучшения фаззинга и invariant‑тестов
В релизе также оптимизировали фаззинг‑ и invariant‑тестирование и добавили новые команды семейства forge fuzz. Если вы активно используете property‑based подход (инварианты «не нарушаются ни при каких последовательностях действий»), обновление будет особенно заметным.
Линтер стал заметно полезнее
Команда расширила forge lint большим набором детекторов: от потенциальных проблем безопасности до ошибок корректности и неэффективных паттернов по газу. Для части проектов это может сократить зависимость от внешних линтеров и упростить CI: меньше разрозненных проверок — меньше шума в пайплайне.
Важные изменения, из-за которых тесты могут «сломаться»
Релиз не только добавляет новые возможности, но и меняет поведение по умолчанию — это типичная причина, почему после обновления внезапно появляются падения.
Изоляция тестов включена по умолчанию
Теперь тесты запускаются в режиме изоляции, из‑за чего чаще встречается работа с «непрогретым» хранилищем. На практике это может влиять на измерения газа и на логику, завязанную на состояние между вызовами.
Transient‑переменные очищаются между вызовами в рамках теста
Если у вас были тестовые сценарии, которые неявно рассчитывали на сохранение transient‑состояния между шагами, после обновления они могут начать падать. Хорошая новость в том, что поведение становится ближе к реальной среде исполнения — но тесты придётся адаптировать.
Распространение: больше не через npm
Начиная с Foundry 1.8.0, проект больше не распространяется через npm. Для команд это означает, что нужно пересмотреть инструкции установки (особенно в CI) и зафиксировать единый способ обновления внутри организации, чтобы избежать ситуации «у всех разные версии».
Кому стоит обратить внимание на релиз
- Командам со сложной логикой контрактов — новые режимы тестирования помогают находить нетривиальные баги.
- Тем, кто строит строгий CI — расширенный линтер и mutation‑подход усиливают качество проверок перед деплоем.
- Проектам с чувствительными к газу тестами — изменения изоляции могут повлиять на ожидания по потреблению газа и потребуют корректировок.
Короткий чек‑лист перед обновлением
- Запланируйте прогон тестов на отдельной ветке и проверьте, не изменились ли gas‑ожидания.
- Если есть нестабильные тесты, попробуйте прогнать их с новыми режимами (mutation/brutalize) — иногда это быстро показывает, где слабые места.
- Обновите документацию команды по установке Foundry (особенно для CI), учитывая отказ от npm‑распространения.
Foundry 1.8.0 выглядит как релиз, который повышает планку качества: он не столько про «ещё одну фичу», сколько про более строгую проверку того, что контракт действительно ведёт себя безопасно и предсказуемо.
