[IMPROVEMENT] Make E2E Tests Resilient to Foundry Version Differences
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 38/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- shell, solidity
- Área
- blockchain, testing
Línea de trabajo
Start by reading local/punchswap/e2e_punchswap.sh and solidity/script/02_DeployUSDC_WBTC_Create2.s.sol to trace how token addresses are predicted and used. Then inspect local/punchswap/punchswap.env and solidity/script/03_UseMintedUSDCWBTC_AddLPAndSwap.s.sol for the configured addresses and strategy initialization. Done means the E2E flow uses addresses that match deployed tokens across supported Foundry versions; the issue also proposes documenting the tested version in the README.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Issue to be solved
When running the e2e test script (e2e_punchswap.sh), the predicted addresses of USDC and WBTC tokens differ depending on the Foundry version installed locally. This address mismatch causes:
- E2E tests to fail or not complete successfully
- FlowVaultsStrategies contract to be initialized with hardcoded addresses (e.g.,
0xaCCF0c4EeD4438Ad31Cd340548f4211a465B6528) that don't actually have ERC20 tokens deployed at them - Runtime interaction failures when working with the emulator because strategies reference non-existent token contracts
Current Behavior
The deployment script 02_DeployUSDC_WBTC_Create2.s.sol uses Foundry's CREATE2 deployer to predict token addresses:
address predictedUSDC = _predict(CREATE2_DEPLOYER, SALT_USDC, usdcInit);
address predictedWBTC = _predict(CREATE2_DEPLOYER, SALT_WBTC, wbtcInit);
These predicted addresses are then:
- Used as configuration values in
punchswap.env:USDC_ADDR=0xaCCF0c4EeD4438Ad31Cd340548f4211a465B6528WBTC_ADDR=0x374BF2423c6b67694c068C3519b3eD14d3B0C5d1
- Passed as initialization arguments when deploying FlowVaultsStrategies
However, different Foundry versions appear to generate different predicted addresses for the same deployment parameters, breaking the entire deployment and testing flow.
Impact
- Test Reliability: E2E tests are not reproducible across different development environments
- Configuration Mismatch: Hard-coded addresses in
punchswap.envdon't have actual ERC20 tokens deployed at them when Foundry versions differ - Deployment Failures: FlowVaultsStrategies contracts are initialized with addresses that point to empty/non-token contracts, causing all token interactions to fail
- Team Coordination: Different team members may experience different test results based on their local Foundry installation
Suggest A Solution
Inform Foundry Version to be used locally
Technical Implementation:
-
Document the working Foundry version in README:
This project has been tested with: forge Version: 1.4.3-v1.4.3 Commit SHA: fa9f934bdac4bcf57e694e852a61997dda90668a Build Timestamp: 2025-10-22T04:37:38.758664000Z Build Profile: maxperfTo install this specific version:
foundryup --version nightly-fa9f934bdac4bcf57e694e852a61997dda90668a
Tradeoffs:
- ✅ Simple to implement
- ✅ Provides clear guidance to developers
- ❌ Relies on developers manually checking and installing correct version
- ❌ No automated enforcement
Caveats and Considerations for the Future
-
CI/CD Integration: Whichever solution is chosen should work seamlessly in GitHub Actions and other automated environments
-
Address Registry: For long-term maintainability, consider implementing a deployment address registry pattern (similar to what protocols like Aave use) where all contract addresses are stored in a central registry contract or JSON file
Related Files
local/punchswap/e2e_punchswap.sh- E2E test orchestration scriptsolidity/script/02_DeployUSDC_WBTC_Create2.s.sol- Token deployment with CREATE2local/punchswap/punchswap.env- Configuration file with hard-coded addressessolidity/script/03_UseMintedUSDCWBTC_AddLPAndSwap.s.sol- Strategy deployment using predicted addresses
What are you currently working on that this is blocking?
No response
- Lenguaje dominante
- Cadence
- Estrellas
- 41
- Forks
- 0
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de onflow/FlowYieldVaults
-
Clarify contract version namingAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
onflow/FlowYieldVaults#274 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
onflow/FlowYieldVaults#273 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
onflow/FlowYieldVaults#272 ·
-
Remove outdated documentationAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
onflow/FlowYieldVaults#271 ·
-
Move all test files into `./cadence/tests`Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
onflow/FlowYieldVaults#270 ·
Todos los issues de onflow/FlowYieldVaults
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
btclib-org/btclib-node#1833 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 Menos de una hora Aptitud para principiantes 85/100
ethersphere/bee#5652 ·
Los mantenedores suelen responder en 2 días
-
enhancement good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
Request: add {USDT Lis}Abiertolist-request
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Uniswap/tokenlists-org#3325 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100