Write Solidity integration tests for EigenLayer contracts. Use when the user asks to write integration tests, test user flows, test cross-contract interactions, or test upgrade scenarios. Follows project conventions with User/AVS actors and numbered action steps.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Write Solidity integration tests for EigenLayer contracts. Use when the user asks to write integration tests, test user flows, test cross-contract interactions, or test upgrade scenarios. Follows project conventions with User/AVS actors and numbered action steps.
allowed-tools
Read, Glob, Grep, Edit, Write, Bash(forge:*)
Integration Test Writer
Write comprehensive integration tests for EigenLayer Solidity contracts following the project's established conventions.
Overview
Integration tests orchestrate the deployment of all EigenLayer core contracts to test high-level user flows across multiple contracts. There are three test modes:
Local Integration Tests - Deploy fresh contracts and test user flows
Fork Tests - Fork mainnet, upgrade all contracts to latest implementations, then run the integration test suite
Upgrade Tests - Fork mainnet, perform actions on OLD contracts, then upgrade and verify compatibility
Test Function Signature
All integration test functions MUST:
Be named testFuzz_action1_action2_... describing the flow
Take uint24 _random (or _r) as the only parameter - this seeds randomness
Use the rand(_random) modifier to initialize the random seed
function testFuzz_deposit_delegate_queue_complete(uint24 _random) public rand(_random) {
// Test implementation
}
The rand() modifier initializes the test's random seed, which is used by helper functions like to generate deterministic random values for reproducible tests.
If a check doesn't exist, add it to IntegrationChecks.t.sol:
function check_NewAction_State(
User staker,
IStrategy[] memory strategies,
uint[] memory expectedValues
) internal {
// Use assert_Snap_* for before/after comparisons
assert_Snap_Added_Staker_DepositShares(
staker, strategies[0], expectedValues[0], "should have added shares"
);
// Or use regular assertions for absolute checks
assertEq(
someContract.getValue(address(staker)),
expectedValue,
"value should match expected"
);
}
Randomness and Configuration
The rand(_r) Modifier
Every test function takes a uint24 _r parameter and uses the rand(_r) modifier:
function testFuzz_deposit_delegate(uint24 _r) public rand(_r) {
// _r seeds all random generation in this test
// This makes tests reproducible - same _r = same test execution
}
The rand() modifier initializes the random seed used by all _newRandom* helper functions. This ensures:
Reproducibility: Same seed produces same random values
Fuzz coverage: Foundry automatically runs with many different seeds
Asset and User Type Configuration
Use _configRand or _configAssetTypes to control what types of users/assets are created:
function testFuzz_example(uint24 _r) public rand(_r) {
// Full configuration
_configRand({
_randomSeed: _r,
_assetTypes: HOLDS_LST | HOLDS_ETH,
_userTypes: DEFAULT | ALT_METHODS
});
// Or just configure asset types (simpler)
_configAssetTypes(HOLDS_LST);
// Create users - will use the configured randomization
(User staker, IStrategy[] memory strategies, uint[] memory tokenBalances) = _newRandomStaker();
}
Asset Types:
HOLDS_LST - User holds liquid staking tokens
HOLDS_ETH - User holds native ETH (beacon chain)
HOLDS_ALL - User holds both
User Types:
DEFAULT - Standard User contract
ALT_METHODS - User that uses alternative method signatures
# Run all integration tests locally (fresh contract deployment)
forge t --mc Integration
# Run mainnet fork tests (upgrades mainnet contracts to latest, then runs tests)# Requires RPC_MAINNET environment variableenv FOUNDRY_PROFILE=forktest forge t --mc Integration
# Run upgrade tests only (tests upgrade compatibility)env FOUNDRY_PROFILE=forktest forge t --mc Integration_Upgrade
# Run specific test
forge t --match-test testFuzz_deposit_delegate
# Run with verbosity
forge t --mc Integration -vvv
Fork Tests vs Local Tests
Mode
Command
What Happens
Local
forge t --mc Integration
Deploys fresh contracts, runs tests
Fork
env FOUNDRY_PROFILE=forktest forge t --mc Integration
Forks mainnet, upgrades ALL contracts to latest repo implementations, runs tests
Upgrade
env FOUNDRY_PROFILE=forktest forge t --mc Integration_Upgrade
Forks mainnet, runs pre-upgrade actions on OLD contracts, then upgrades and tests compatibility
Fork tests ensure that the latest contract code works correctly when upgrading from the current mainnet state. The test framework automatically upgrades all proxy contracts to the latest implementations before running tests.
Naming Conventions
Contract Names
Pattern
Purpose
Integration_FlowName_Base
Base contract with shared _init() setup
Integration_FlowName_Variant
Test contract for specific flow variant
Integration_Upgrade_FeatureName
Upgrade test for a feature
Test Function Names
All test functions follow the pattern: testFuzz_action1_action2_...(uint24 _random) public rand(_random)
