## Implement E2E Testing Framework with Isolated Networks ### Summary Refactors the existing E2E testing infrastructure to provide isolated test environments with parallel execution support. Each test suite now runs in its own network namespace, preventing resource conflicts. ### Key Changes - **New Testing Framework** (`test/framework/`): Base classes for test lifecycle management with automatic setup/teardown - **Launcher Module** (`test/launcher/`): Extracted network orchestration logic from CLI handlers for reusability - **Parallel Execution**: Added `test-parallel.ts` script with concurrency limits to prevent resource exhaustion - **Test Isolation**: Each suite gets unique network IDs (format: `suiteName-timestamp`) and Docker networks - **Improved Test Organization**: Migrated tests to new framework, deprecated old test structure ### Test Improvements - Added 4 new test suites demonstrating framework usage. : - `contracts.test.ts` - Smart contract deployment/interaction - `datahaven-substrate.test.ts` - Substrate API operations - `cross-chain.test.ts` - Snowbridge cross-chain messaging - `ethereum-basic.test.ts` - Ethereum network operations > [!WARNING] The test suites themselves are bad and shouldn't be consider examples of good tests. They were AI generated just to test the concurrency of test runners ### Documentation - Added comprehensive framework overview (`E2E_FRAMEWORK_OVERVIEW.md`) - Updated README with parallel testing commands - Added test patterns and best practices ### Breaking Changes - Old test suites moved to `e2e - DEPRECATED/` directory - Test execution now requires extending `BaseTestSuite` class ### Testing Run tests with: `bun test:e2e` or `bun test:e2e:parallel` (with concurrency limits) ### TODO - [ ] Implement good test examples. - [ ] Implement useful test utils (like waiting for an event to show up in DataHaven or Ethereum). - [ ] Enforce tests with CI (currently cannot be done due to intermittent error when sending a transaction with PAPI). --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: undercover-cactus <lola@moonsonglabs.com>
6.5 KiB
DataHaven E2E Testing
Quick start guide for running DataHaven end-to-end tests. For comprehensive documentation, see E2E Testing Guide.
Pre-requisites
- Kurtosis: For launching test networks
- Bun v1.2 or higher: TypeScript runtime and package manager
- Docker: For container management
- Foundry: To deploy contracts
- Helm: The Kubernetes Package Manager
MacOS
Important
If you are running this on a Mac,
zigis a pre-requisite for crossbuilding the node. Instructions for installation can be found here.
Quick Start
# Install dependencies
bun i
# Interactive CLI to launch a full local DataHaven network
bun cli launch
# Run all the e2e tests
bun test:e2e
# Run all the e2e tests with limited concurrency
bun test:e2e:parallel
# Run a specific test suite
bun test suites/some-test.test.ts
For more information on the E2E testing framework, see the E2E Testing Framework Overview.
Other Common Commands
| Command | Description |
|---|---|
bun cli stop |
Stop all local DataHaven networks (interactive, will ask for confirmation on each component of the network) |
bun cli deploy |
Deploy the DataHaven network to a remote Kubernetes cluster |
bun generate:wagmi |
Generate contract TypeScript bindings for the contracts in the contracts directory |
bun generate:types |
Generate Polkadot API types |
bun generate:types:fast |
Generate Polkadot API types with the --fast-runtime feature enabled |
Local Network Deployment
Follow these steps to set up and interact with your local network:
-
Deploy a minimal test environment
bun cli launchThis script will:
- Check for required dependencies.
- Launch a DataHaven solochain.
- Start a Kurtosis network which includes:
- 2 Ethereum Execution Layer clients (reth)
- 2 Ethereum Consensus Layer clients (lodestar)
- Blockscout Explorer services for EL (if enabled with --blockscout)
- Dora Explorer service for CL
- Deploy DataHaven smart contracts to the Ethereum network. This can optionally include verification on Blockscout if the
--verifiedflag is used (requires Blockscout to be enabled). - Perform validator setup and funding operations.
- Set parameters in the DataHaven chain.
- Launch Snowbridge relayers.
- Perform validator set update.
Note
If you want to also have the contracts verified on Blockscout, you can pass the
--verifiedflag to thebun cli launchcommand, along with the--blockscoutflag. This will do all the previous, but also verify the contracts on Blockscout. However, note that this takes some time to complete. -
Explore the network
- Block Explorer: http://127.0.0.1:3000.
- Kurtosis Dashboard: Run
kurtosis webto access. From it you can see all the services running in the network, as well as their ports, status and logs.
Troubleshooting
E2E Network Launch doesn't work
Script halts unexpectedly
When running bun cli launch the script appears to halt after the following:
## Setting up 1 EVM.
==========================
Chain 3151908
Estimated gas price: 2.75 gwei
Estimated total gas used for script: 71556274
Estimated amount required: 0.1967797535 ETH
==========================
This is due to how forge streams output to stdout, but is infact still deploying contracts to the chain. You should be able to see in blockscout the deploy script is indeed still working.
Errors with deploying forge scripts on kurtosis network
Try running forge clean to clear any spurious build artefacts, and running forge build again. Also try deploying manually to the still running kurtosis network.
Blockscout is empty
If you look at the browser console, if you see the following:
Content-Security-Policy: The page's settings blocked the loading of a resource (connect-src) at http://127.0.0.1:3000/node-api/proxy/api/v2/stats because it violates the following directive: "connect-src ' ...
this is a result of CORS and CSP errors due to running this as a local docker network.
Make sure you are connected directly to http://127.0.0.1:3000 (not localhost).
Alternatively, you can try installing a browser addon such as anti-CORS / anti-CSP to circumvent this problem.
Weird forge Errors
In the /contracts directory, you can try to run forge clean and forge build to see if it fixes the issue.
Linux: See if disabling ipV6 helps
I have found that ipV6 on Arch Linux does not play very nicely with Kurtosis networks. Disabling it completely fixed the issue for me.
macOS: Verify Docker networking settings
If using Docker Desktop, make sure settings have permissive networking enabled.
Polkadot-API types don't match expected runtime types
If you've made changes to the runtime types, you need to re-generate the TS types for the Polkadot-API. Don't worry, this is fully automated.
From the ./test directory run the following command:
bun generate:types
This script will:
- Compile the runtime using
cargo build --releasein the../operatordirectory. - Re-generate the Polkadot-API types using the newly built WASM binary.
Note
The script uses the
--releaseflag by default, meaning it uses the WASM binary from./operator/target/release. If you need to use a different build target, you may need to adjust the script or run the steps manually.
