Технические модули

Sushi: воспроизводимые E2E-проверки интерфейса на изолированной копии Polygon

Тестовый компонент интерфейса Sushi: браузерные проверки работают с mock-кошельком, закреплённым состоянием Polygon и записанными HTTP-ответами, а отдельный инфраструктурный harness проверяет саму изоляцию тестов.

16.10.2026·22 источников·По описаниям проекта ↗

КЛЮЧЕВЫЕ СВЕДЕНИЯ

Паспорт проекта

По первоисточникам

Тип: Технические модули
Задача: Проверять состояние и исполнение независимо от визуальных уведомлений и сохранять изоляцию повторяемых сценариев.
Для кого: В описании не уточняется
Технологии: API / JSON
Что потребуется: Нужны зависимости pnpm и браузер Chromium для Playwright.
Основание: 22 первоисточников

СУТЬ

За 30 секунд

01 / Зачем

Проверять состояние и исполнение независимо от визуальных уведомлений и сохранять изоляцию повторяемых сценариев.

02 / Как

PR-набор проверяет операции интерфейса и подтверждает receipts и изменения состояния отдельно от уведомлений UI.

03 / Результат

Результаты проверок, отчёты HTML/JSON и артефакты; в полном наборе отдельно проверяются квитанции и изменения балансов/позиций, а не только сообщение интерфейса.

ПОСЛЕДОВАТЕЛЬНОСТЬ

Как это работает

На входе

API

Тестовые сценарии, mock-кошелёк, записи HTTP и manifest с блоком, отправителем, версией API, токенами и суммами. Для полного fork-набора нужен архивный Polygon RPC; отдельный harness обходится без этого доступа.

Механизм

PR-набор проверяет операции интерфейса и подтверждает receipts и изменения состояния отдельно от уведомлений UI. Harness проверяет маршрутизацию RPC, восстановление snapshot, замену работника при повторе и отказ на неуспешной квитанции.

Результат

JSON

ПОДРОБНОСТИ

Что важно понять

Техническое устройство

Работники имеют отдельные proxy endpoint и Viem-клиенты. Перед каждым тестом создаётся snapshot, восстановление идёт после закрытия браузера. Время блоков движется на секунду за блок; mock-кошелёк заранее оценивает газ и передаёт точный лимит. Loader отклоняет несовпадающий запрос вместо выдачи успешной чужой записи.

Для чего создано

Сценарии использования

Проверки PR и инфраструктуры повторов; сравнение одного и двух работников с сохранением отчётов; controlled fork-сценарии интерфейса Sushi.

Идея решения

Закрепить исходное состояние сети и внешние ответы, разделить mutable-состояние работников и восстанавливать snapshot после теста; затем проверять результат по квитанции и состоянию, а не только по UI.

Какую задачу описывает источник

Документ описывает недооценку газа неявным путём Anvil 1.8.1 для V3-транзакций; явная оценка в mock-кошельке нужна для соответствия проверяемому пути исполнения.

ГОТОВНОСТЬ К ПРОВЕРКЕ

Что известно из описания

Полнота описанияЗапуск не проверялся

МеханизмОписано

ТребованияОписано

ОграниченияОписано

Что потребуется

Нужны зависимости pnpm и браузер Chromium для Playwright.
Для fork-набора зафиксированы блок 71015789, Anvil 1.8.1, тестовая среда и chain ID 137; несоответствующая версия Anvil отклоняется.
Условия отдельного инфраструктурного harness мягче: ему не нужны сборка приложения и архивный RPC.

Что учитывать

Документ не доказывает безопасность реальных контрактов или результат реальной операции.
Замер 2026 года использовал Anvil 1.5.1, до нынешней явной оценки газа, и не переносится на CI.
Legacy cross-chain тест исключён, часть сценариев остаётся будущим покрытием; visual stories не покрывают реальный checkout, подпись и analytics.

СМОТРИМ ГЛУБЖЕ

Комментарий NeoBridge

Общая справка

E2E и harness — E2E проверяет сквозной пользовательский сценарий; harness — инфраструктура, которая организует и контролирует выполнение проверок.
Fork, snapshot и mock — Fork здесь — локальная копия состояния сети; snapshot — снимок для восстановления; mock — управляемая имитация внешнего компонента.
RPC, receipt и gas — RPC — удалённый вызов операции; receipt — квитанция исполнения; gas — мера вычислительных ресурсов транзакции.
Anvil и Viem — Anvil предоставляет локальную тестовую сеть; Viem — программный клиент для взаимодействия с ней.
CI и PR — Автоматические проверки изменений и запрос на включение изменений в проект соответственно.
API — Правила, по которым программы обращаются друг к другу: например, запрашивают данные или передают команду.

Что стоит уточнить

Какие сценарии из отложенного покрытия реализованы в выбранной версии? Сохранённый документ прямо оставляет cross-chain, Solana и некоторые wallet-сценарии за текущей границей.
Какая лицензия распространяется на тестовый компонент и используемые записи? README содержит disclaimer, но полный текст лицензии в пакете не установлен.

Основания и справочные материалы

API ↗

↗

ОСНОВАНИЯ

Из первоисточников

22 ссылок

Редакционный обзор NeoBridge Insight по материалам источников ниже. Права на исходные тексты, код и изображения принадлежат их правообладателям. Условия использования указаны в первоисточниках.

Независимое тестирование проекта не проводилось.

github.com

← Вернуться к проектам Продолжить исследование ↗