ethereum-optimism / ethereum-optimism/actions

Full e2e system tests

Open
#335 1 comment 0 reactions 0 assignees View on GitHub
good first issue help wanted
Dominant language
TypeScript
Stars
32
Forks
25
Avg merge
10h 20m
Merged PRs (30d)
16

Description

## Problem

The SDK has unit tests with mocked dependencies but no end-to-end system tests that exercise the full flow against real contracts. Encoding bugs, approval flows, recipient handling, and provider routing are never validated on-chain.

## What we need

### Full matrix coverage

Test every combination a developer would encounter:
- **Every wallet provider** (Privy, Turnkey, Dynamic, SmartWallet) × **every chain** (Mainnet, OP Mainnet, Base) × **every namespace function** (getQuote, execute, getMarkets, getMarket, getPosition, openPosition, closePosition)
- **Every swap provider** (Uniswap, Velodrome/Aerodrome) across their supported router types and pool types
- **Every lend provider** (Aave, Morpho) including native ETH paths (WETHGateway) and ERC20 paths
- Both namespace paths: ActionsNamespace (read-only, no wallet) and WalletNamespace (full execution)

### Real execution, no mocks

- Use Anvil forks against Mainnet, OP Mainnet, and Base
- Create real ActionsConfig instances with real providers and real ChainManagers
- Use funded test accounts from Anvil
- Verify on-chain state after execution: token balances, allowances, receipts, recipient addresses

### Test structure and shared state

- Use `beforeAll` / `afterAll` hooks to set up expensive resources (Anvil forks, funded accounts, provider instances) once per suite, not per test
- Tests within a suite should cascade context — e.g., a quote test produces a quote that the execute test consumes, an openPosition test creates state that getPosition and closePosition verify
- Build helper functions and abstractions to minimize per-test boilerplate — e.g., `expectBalanceChange(token, address, fn)`, `withAnvilFork(chain, fn)`, `createFundedActions(chain)`
- Reduce actual test code as much as possible — the matrix should be driven by data (arrays of providers, chains, assets) rather than duplicated test bodies
- Shared utilities in a `setup.ts` or `helpers.ts` that all system test files import

### Edge cases worth covering

- Quote from Actions namespace executed through Wallet namespace (recipient mismatch → re-encoding)
- Existing allowances (verify no redundant approval txs)
- Native ETH swaps
- Quote expiration (advance Anvil time)
- Blocklist enforcement on getMarkets

### Expect to find real bugs

This work will likely surface real bugs in encoding, approval flows, or edge cases. The scope of this issue is **setting up the test matrix and CI job, not fixing the bugs**. When a test reveals a real issue:
1. Write the test anyway
2. Skip or comment out the failing test with a clear note
3. Create a separate issue describing the bug
4. Link the issue in a `// TODO(#xxx)` comment next to the skipped test

Do not block this PR on fixing discovered bugs.

### Infrastructure

- Separate vitest project with extended timeouts
- Separate CI job (see #332, #333) with Anvil and RPC env vars
- Randomized test order

## Existing foundation

`VelodromeSwapProvider.network.test.ts` already has Anvil fork tests for quoting. Expand from there.

## Related

- #332 — Add network fork tests to CI
- #333 — Parallelize tests / split CI into per-package jobs

Contributor guide

Open the contributing guide

Research direction

Start by reading and running VelodromeSwapProvider.network.test.ts, the existing Anvil fork foundation. Then review #332 and #333 for CI and test-splitting requirements before mapping the provider, chain, namespace, swap, and lending matrix into shared system-test setup. Done means the fork-based suites, state verification, edge cases, and separate CI job are in place, with discovered bugs tracked separately.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, typescript
Domain
blockchain, ci-cd, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.