2025-07-16 16:51:07 +00:00
# DataHaven E2E Testing
2025-04-08 15:42:45 +00:00
2025-10-06 16:12:55 +00:00
End-to-end testing framework for DataHaven, providing automated network deployment, contract interaction, and cross-chain scenario testing. This directory contains all tools needed to launch a complete local DataHaven network with Ethereum, Snowbridge relayers, and run comprehensive integration tests.
For comprehensive documentation, see [E2E Testing Guide ](./docs/E2E_TESTING_GUIDE.md ).
2025-04-08 15:42:45 +00:00
## Pre-requisites
- [Kurtosis ](https://docs.kurtosis.com/install ): For launching test networks
2025-06-19 00:01:22 +00:00
- [Bun ](https://bun.sh/ ) v1.2 or higher: TypeScript runtime and package manager
2025-04-08 15:42:45 +00:00
- [Docker ](https://www.docker.com/ ): For container management
2025-07-16 16:51:07 +00:00
- [Foundry ](https://getfoundry.sh/introduction/installation/ ): To deploy contracts
- [Helm ](https://helm.sh/docs/intro/install/ ): The Kubernetes Package Manager
2025-04-08 15:42:45 +00:00
test: Update validator set e2e test (#126)
## Add E2E validator-set update flow
- feat: `test/utils/validators.ts` for on-demand validator
orchestration.
- feat: `test/suites/validator-set-update.test.ts` covering allowlist →
register → update.
- some minor launcher updates: avoid docker cache, add `--platform` when
building datahaven image, avoid sending validator-set update on launch.
- Helpers: ABI shortcut in `test/utils/contracts.ts`; config tweaks in
`test/configs/validator-set.json`.
- Minor cleanup/formatting across `test/launcher/*`,
`test/scripts/setup-validators.ts`, and related tests.
- added `keepAlive` flag to `BaseTestSuite`, in order to avoid tearing
down the network while debugging. Defaults, obviously, to false.
- added a `failOnTomeout` option on to waitForDataHavenEvents() so the
test fails of the timeout is reached and no event was captured.
### Coverage
- The test simulates an scenario in which we have two active authorities
(alice and bob), which are running, and registered as operators, which
is the normal state after the chain launches. Then:
- It launches two more nodes (charlie and dave)
- It add the nodes to allowlist and register them as operators
- It sends the validator set update message
- Checks that the validator update message was propagated through the
gateway and arrived the external-validators pallet
- Checks that the chain continues producing blocks
### Notes
The last test case has a timeout of 10 minutes. This is to respect
propagation times of the message through the relayers. We are testing
that the external validators pallet actually updated the validator set.
Locally, I could expect 5~6 minutes, I just wanted to be on the safe
side. CI is passing showing that this was enough indeed.
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-10-02 11:23:40 +00:00
#### MacOS
If you are running this on a Mac, `zig` is a pre-requisite for crossbuilding the node. Instructions for installation can be found [here ](https://ziglang.org/learn/getting-started/ ).
You may also need to install `libpq` for PostgreSQL connectivity and set the appropriate Rust flags.
perf(CLI): ⚡ Add option to use local Docker build in CLI for faster iteration (#77)
In this PR:
1. Add new `datahaven-node-local.dockerfile` for building a local image
with the locally built DataHaven Node binary. This severely improves
iteration speed on running `bun cli` if there are changes in the DH
node. Previously, it relied on the published dockerfile, which builds
the Cargo project inside of it, taking +20m even with no changes.
2. Building this local dockerfile is integrated to the CLI, which now
also asks if the user wants to rebuild the local docker image of the DH
node.
3. A new script `cargo-crossbuild` is added, to be able to build the
DataHaven node Cargo project both from Mac and Linux, with the target
being `x86_64-unknown-linux-gnu`. For building from Mac, it uses `cargo
zigbuild`, so `zig` is now a dependency. Building for this target is
needed because the docker image is an Ubuntu image, so it will need to
run a linux binary.
4. Added `zig` as dependency in docs.
5. CI still uses the docker image built by the CI itself, which builds
the Cargo project inside of it. The CI can take advantage of caching for
this.
2025-05-16 21:04:40 +00:00
test: Update validator set e2e test (#126)
## Add E2E validator-set update flow
- feat: `test/utils/validators.ts` for on-demand validator
orchestration.
- feat: `test/suites/validator-set-update.test.ts` covering allowlist →
register → update.
- some minor launcher updates: avoid docker cache, add `--platform` when
building datahaven image, avoid sending validator-set update on launch.
- Helpers: ABI shortcut in `test/utils/contracts.ts`; config tweaks in
`test/configs/validator-set.json`.
- Minor cleanup/formatting across `test/launcher/*`,
`test/scripts/setup-validators.ts`, and related tests.
- added `keepAlive` flag to `BaseTestSuite`, in order to avoid tearing
down the network while debugging. Defaults, obviously, to false.
- added a `failOnTomeout` option on to waitForDataHavenEvents() so the
test fails of the timeout is reached and no event was captured.
### Coverage
- The test simulates an scenario in which we have two active authorities
(alice and bob), which are running, and registered as operators, which
is the normal state after the chain launches. Then:
- It launches two more nodes (charlie and dave)
- It add the nodes to allowlist and register them as operators
- It sends the validator set update message
- Checks that the validator update message was propagated through the
gateway and arrived the external-validators pallet
- Checks that the chain continues producing blocks
### Notes
The last test case has a timeout of 10 minutes. This is to respect
propagation times of the message through the relayers. We are testing
that the external validators pallet actually updated the validator set.
Locally, I could expect 5~6 minutes, I just wanted to be on the safe
side. CI is passing showing that this was enough indeed.
---------
Co-authored-by: Steve Degosserie <723552+stiiifff@users.noreply.github.com>
Co-authored-by: Ahmad Kaouk <56095276+ahmadkaouk@users.noreply.github.com>
2025-10-02 11:23:40 +00:00
```bash
# Install libpq using Homebrew
brew install zig
# Install libpq using Homebrew
brew install libpq
# Set environment variables for Rust compilation
export PKG_CONFIG_PATH="/opt/homebrew/opt/libpq/lib/pkgconfig"
export CPPFLAGS="-I$(brew --prefix libpq)/include"
export LDFLAGS="-L$(brew --prefix libpq)/lib"
export PKG_CONFIG_PATH="$(brew --prefix libpq)/lib/pkgconfig"
# Add to your shell profile (~/.zshrc or ~/.bash_profile) to persist
echo 'export PKG_CONFIG_PATH="/opt/homebrew/opt/libpq/lib/pkgconfig"' >> ~/.zshrc
echo 'export CPPFLAGS="-I$(brew --prefix libpq)/include"' >> ~/.zshrc
echo 'export LDFLAGS="-L$(brew --prefix libpq)/lib"' >> ~/.zshrc
echo 'export PKG_CONFIG_PATH="$(brew --prefix libpq)/lib/pkgconfig"' >> ~/.zshrc
```
perf(CLI): ⚡ Add option to use local Docker build in CLI for faster iteration (#77)
In this PR:
1. Add new `datahaven-node-local.dockerfile` for building a local image
with the locally built DataHaven Node binary. This severely improves
iteration speed on running `bun cli` if there are changes in the DH
node. Previously, it relied on the published dockerfile, which builds
the Cargo project inside of it, taking +20m even with no changes.
2. Building this local dockerfile is integrated to the CLI, which now
also asks if the user wants to rebuild the local docker image of the DH
node.
3. A new script `cargo-crossbuild` is added, to be able to build the
DataHaven node Cargo project both from Mac and Linux, with the target
being `x86_64-unknown-linux-gnu`. For building from Mac, it uses `cargo
zigbuild`, so `zig` is now a dependency. Building for this target is
needed because the docker image is an Ubuntu image, so it will need to
run a linux binary.
4. Added `zig` as dependency in docs.
5. CI still uses the docker image built by the CI itself, which builds
the Cargo project inside of it. The CI can take advantage of caching for
this.
2025-05-16 21:04:40 +00:00
2025-07-16 16:51:07 +00:00
## Quick Start
feat: ✨ Add Polkadot API support to CLI and e2e testing infra (#68)
In this PR:
1. Add [Polkadot API](https://papi.how/) support to `test/` directory
(i.e. the e2e CLI and testing framework) to be able to interact with the
Substrate chain.
1. This allows typed interactions with transactions, constants, storage,
runtime APIs, and non-typed interaction with RPC methods.
2. Types are autogenerated when running `bun i`, from the
`datahaven.scale` file that is part of this repo's version control.
2. Add new utilities file to `papi` related functionalities. For the
time being, generating a new signer from a private key.
3. ~Add a new step to the CLI that sends a transaction to the DataHaven
network. _*THIS SHOULD BE REMOVED SOON, IT'S JUST FOR TESTING
PURPOSES*_~
1. Both steps that send test transactions have been removed from the
CLI, for convenience and being error prone. Their scripts remain usable
for testing purposes if needed.
4. Removes the `apis.rs` files from the runtime definitions. Having them
in a separate file meant that the runtime was not including the Runtime
APIs in the metadata blob, preventing `papi` from creating types from
it. This change can be reapplied after upgrading to `polkadot-sdk`
`stable-2503`. More info
[here](https://github.com/paritytech/polkadot-sdk/issues/6659).
5. Add script to re-generate types, and corresponding docs.
6. Makes logger synchronous to avoid prints happening before logs.
2025-05-13 03:03:21 +00:00
```bash
2025-07-16 16:51:07 +00:00
# Install dependencies
feat: ✨ Add Polkadot API support to CLI and e2e testing infra (#68)
In this PR:
1. Add [Polkadot API](https://papi.how/) support to `test/` directory
(i.e. the e2e CLI and testing framework) to be able to interact with the
Substrate chain.
1. This allows typed interactions with transactions, constants, storage,
runtime APIs, and non-typed interaction with RPC methods.
2. Types are autogenerated when running `bun i`, from the
`datahaven.scale` file that is part of this repo's version control.
2. Add new utilities file to `papi` related functionalities. For the
time being, generating a new signer from a private key.
3. ~Add a new step to the CLI that sends a transaction to the DataHaven
network. _*THIS SHOULD BE REMOVED SOON, IT'S JUST FOR TESTING
PURPOSES*_~
1. Both steps that send test transactions have been removed from the
CLI, for convenience and being error prone. Their scripts remain usable
for testing purposes if needed.
4. Removes the `apis.rs` files from the runtime definitions. Having them
in a separate file meant that the runtime was not including the Runtime
APIs in the metadata blob, preventing `papi` from creating types from
it. This change can be reapplied after upgrading to `polkadot-sdk`
`stable-2503`. More info
[here](https://github.com/paritytech/polkadot-sdk/issues/6659).
5. Add script to re-generate types, and corresponding docs.
6. Makes logger synchronous to avoid prints happening before logs.
2025-05-13 03:03:21 +00:00
bun i
2025-07-16 16:51:07 +00:00
# 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
feat: ✨ Add Polkadot API support to CLI and e2e testing infra (#68)
In this PR:
1. Add [Polkadot API](https://papi.how/) support to `test/` directory
(i.e. the e2e CLI and testing framework) to be able to interact with the
Substrate chain.
1. This allows typed interactions with transactions, constants, storage,
runtime APIs, and non-typed interaction with RPC methods.
2. Types are autogenerated when running `bun i`, from the
`datahaven.scale` file that is part of this repo's version control.
2. Add new utilities file to `papi` related functionalities. For the
time being, generating a new signer from a private key.
3. ~Add a new step to the CLI that sends a transaction to the DataHaven
network. _*THIS SHOULD BE REMOVED SOON, IT'S JUST FOR TESTING
PURPOSES*_~
1. Both steps that send test transactions have been removed from the
CLI, for convenience and being error prone. Their scripts remain usable
for testing purposes if needed.
4. Removes the `apis.rs` files from the runtime definitions. Having them
in a separate file meant that the runtime was not including the Runtime
APIs in the metadata blob, preventing `papi` from creating types from
it. This change can be reapplied after upgrading to `polkadot-sdk`
`stable-2503`. More info
[here](https://github.com/paritytech/polkadot-sdk/issues/6659).
5. Add script to re-generate types, and corresponding docs.
6. Makes logger synchronous to avoid prints happening before logs.
2025-05-13 03:03:21 +00:00
```
2025-04-08 15:42:45 +00:00
2025-10-06 16:12:55 +00:00
## What Gets Launched
The `bun cli launch` command deploys a complete local environment:
1. **Ethereum Network** (via Kurtosis):
- 2x Execution Layer clients (reth)
- 2x Consensus Layer clients (lodestar)
- Blockscout Explorer (optional: `--blockscout` )
- Dora Consensus Explorer
2025-04-08 15:42:45 +00:00
2025-10-06 16:12:55 +00:00
2. **DataHaven Network** :
- Single validator solochain
- EVM compatibility via Frontier
- Fast block times (3s with `--fast-runtime` )
3. **Smart Contracts** :
- EigenLayer AVS contracts deployed to Ethereum
- Optional Blockscout verification (`--verified`)
4. **Snowbridge Relayers** :
- Beacon relay (Ethereum → DataHaven)
- BEEFY relay (DataHaven → Ethereum)
- Execution relay (Ethereum → DataHaven)
- Solochain relay (DataHaven → Ethereum)
5. **Network Configuration** :
- Validator registration and funding
- Parameter initialization
- Validator set updates
For more information on the E2E testing framework, see the [E2E Testing Framework Overview ](./docs/E2E_FRAMEWORK_OVERVIEW.md ).
2025-07-16 16:51:07 +00:00
2025-10-06 16:12:55 +00:00
## Common Commands
| Command | Description |
| ------------------------- | -------------------------------------------------------------------------------------------------- |
| **Network Management** | |
| `bun cli` | Interactive CLI menu for all operations |
| `bun cli launch` | Launch full local network (interactive options) |
| `bun start:e2e:local` | Launch local network (non-interactive) |
| `bun start:e2e:verified` | Launch with Blockscout and contract verification |
| `bun start:e2e:ci` | CI-optimized network launch |
| `bun cli stop` | Stop all services (interactive) |
| `bun stop:dh` | Stop DataHaven only |
| `bun stop:sb` | Stop Snowbridge relayers only |
| `bun stop:eth` | Stop Ethereum network only |
| **Testing** | |
| `bun test:e2e` | Run all E2E test suites |
| `bun test:e2e:parallel` | Run tests with limited concurrency |
| `bun test <file>` | Run specific test file |
| **Code Generation** | |
| `bun generate:wagmi` | Generate TypeScript contract bindings (after contract changes) |
| `bun generate:types` | Generate Polkadot-API types from runtime |
| `bun generate:types:fast` | Generate types with fast-runtime feature |
| **Code Quality** | |
| `bun fmt:fix` | Fix TypeScript formatting with Biome |
| `bun typecheck` | TypeScript type checking |
| **Deployment** | |
| `bun cli deploy` | Deploy to Kubernetes cluster (interactive) |
| `bun build:docker:operator` | Build local Docker image (`datahavenxyz/datahaven:local`) |
2025-07-16 16:51:07 +00:00
## Local Network Deployment
Follow these steps to set up and interact with your local network:
2025-04-08 15:42:45 +00:00
1. **Deploy a minimal test environment**
```bash
2025-07-16 16:51:07 +00:00
bun cli launch
2025-04-08 15:42:45 +00:00
```
This script will:
2025-05-15 21:56:36 +00:00
1. Check for required dependencies.
2. Launch a DataHaven solochain.
3. Start a Kurtosis network which includes:
- 2 Ethereum Execution Layer clients (reth)
2025-06-09 15:29:31 +00:00
- 2 Ethereum Consensus Layer clients (lodestar)
2025-05-15 21:56:36 +00:00
- Blockscout Explorer services for EL (if enabled with --blockscout)
- Dora Explorer service for CL
4. Deploy DataHaven smart contracts to the Ethereum network. This can optionally include verification on Blockscout if the `--verified` flag is used (requires Blockscout to be enabled).
5. Perform validator setup and funding operations.
2025-07-16 16:51:07 +00:00
6. Set parameters in the DataHaven chain.
7. Launch Snowbridge relayers.
8. Perform validator set update.
2025-05-15 21:56:36 +00:00
> [!NOTE]
2025-04-14 19:22:43 +00:00
>
2025-07-16 16:51:07 +00:00
> If you want to also have the contracts verified on Blockscout, you can pass the `--verified` flag to the `bun cli launch` command, along with the `--blockscout` flag. This will do all the previous, but also verify the contracts on Blockscout. However, note that this takes some time to complete.
2025-04-08 15:42:45 +00:00
2. **Explore the network**
- Block Explorer: [http://127.0.0.1:3000 ](http://127.0.0.1:3000 ).
- Kurtosis Dashboard: Run `kurtosis web` to 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
2025-07-16 16:51:07 +00:00
When running `bun cli launch` the script appears to halt after the following:
2025-04-08 15:42:45 +00:00
```shell
## 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:
```browser
feat: ✨ Add Polkadot API support to CLI and e2e testing infra (#68)
In this PR:
1. Add [Polkadot API](https://papi.how/) support to `test/` directory
(i.e. the e2e CLI and testing framework) to be able to interact with the
Substrate chain.
1. This allows typed interactions with transactions, constants, storage,
runtime APIs, and non-typed interaction with RPC methods.
2. Types are autogenerated when running `bun i`, from the
`datahaven.scale` file that is part of this repo's version control.
2. Add new utilities file to `papi` related functionalities. For the
time being, generating a new signer from a private key.
3. ~Add a new step to the CLI that sends a transaction to the DataHaven
network. _*THIS SHOULD BE REMOVED SOON, IT'S JUST FOR TESTING
PURPOSES*_~
1. Both steps that send test transactions have been removed from the
CLI, for convenience and being error prone. Their scripts remain usable
for testing purposes if needed.
4. Removes the `apis.rs` files from the runtime definitions. Having them
in a separate file meant that the runtime was not including the Runtime
APIs in the metadata blob, preventing `papi` from creating types from
it. This change can be reapplied after upgrading to `polkadot-sdk`
`stable-2503`. More info
[here](https://github.com/paritytech/polkadot-sdk/issues/6659).
5. Add script to re-generate types, and corresponding docs.
6. Makes logger synchronous to avoid prints happening before logs.
2025-05-13 03:03:21 +00:00
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 ' ...
2025-04-08 15:42:45 +00:00
```
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 ](https://chromewebstore.google.com/detail/anti-cors-anti-csp/fcbmpcbjjphnaohicmhefjihollidgkp ) 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.
feat: ✨ Add Polkadot API support to CLI and e2e testing infra (#68)
In this PR:
1. Add [Polkadot API](https://papi.how/) support to `test/` directory
(i.e. the e2e CLI and testing framework) to be able to interact with the
Substrate chain.
1. This allows typed interactions with transactions, constants, storage,
runtime APIs, and non-typed interaction with RPC methods.
2. Types are autogenerated when running `bun i`, from the
`datahaven.scale` file that is part of this repo's version control.
2. Add new utilities file to `papi` related functionalities. For the
time being, generating a new signer from a private key.
3. ~Add a new step to the CLI that sends a transaction to the DataHaven
network. _*THIS SHOULD BE REMOVED SOON, IT'S JUST FOR TESTING
PURPOSES*_~
1. Both steps that send test transactions have been removed from the
CLI, for convenience and being error prone. Their scripts remain usable
for testing purposes if needed.
4. Removes the `apis.rs` files from the runtime definitions. Having them
in a separate file meant that the runtime was not including the Runtime
APIs in the metadata blob, preventing `papi` from creating types from
it. This change can be reapplied after upgrading to `polkadot-sdk`
`stable-2503`. More info
[here](https://github.com/paritytech/polkadot-sdk/issues/6659).
5. Add script to re-generate types, and corresponding docs.
6. Makes logger synchronous to avoid prints happening before logs.
2025-05-13 03:03:21 +00:00
### 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:
```bash
bun generate:types
```
This script will:
1. Compile the runtime using `cargo build --release` in the `../operator` directory.
2. Re-generate the Polkadot-API types using the newly built WASM binary.
2025-05-15 21:56:36 +00:00
> [!NOTE]
feat: ✨ Add Polkadot API support to CLI and e2e testing infra (#68)
In this PR:
1. Add [Polkadot API](https://papi.how/) support to `test/` directory
(i.e. the e2e CLI and testing framework) to be able to interact with the
Substrate chain.
1. This allows typed interactions with transactions, constants, storage,
runtime APIs, and non-typed interaction with RPC methods.
2. Types are autogenerated when running `bun i`, from the
`datahaven.scale` file that is part of this repo's version control.
2. Add new utilities file to `papi` related functionalities. For the
time being, generating a new signer from a private key.
3. ~Add a new step to the CLI that sends a transaction to the DataHaven
network. _*THIS SHOULD BE REMOVED SOON, IT'S JUST FOR TESTING
PURPOSES*_~
1. Both steps that send test transactions have been removed from the
CLI, for convenience and being error prone. Their scripts remain usable
for testing purposes if needed.
4. Removes the `apis.rs` files from the runtime definitions. Having them
in a separate file meant that the runtime was not including the Runtime
APIs in the metadata blob, preventing `papi` from creating types from
it. This change can be reapplied after upgrading to `polkadot-sdk`
`stable-2503`. More info
[here](https://github.com/paritytech/polkadot-sdk/issues/6659).
5. Add script to re-generate types, and corresponding docs.
6. Makes logger synchronous to avoid prints happening before logs.
2025-05-13 03:03:21 +00:00
>
> The script uses the `--release` flag 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.
2025-10-06 16:12:55 +00:00
## Project Structure
```
test/
├── suites/ # E2E test suites
│ ├── contracts.test.ts # Contract deployment & configuration
│ ├── cross-chain.test.ts # Cross-chain message passing
│ ├── datahaven-substrate.test.ts # Block production & finality
│ ├── ethereum-basic.test.ts # Ethereum network validation
│ ├── native-token-transfer.test.ts # Cross-chain token transfers
│ ├── rewards-message.test.ts # Validator rewards distribution
│ └── validator-set-update.test.ts # Dynamic validator set updates
├── framework/ # Test utilities & helpers
│ ├── connectors.ts # Network connectors
│ ├── manager.ts # Test environment manager
│ ├── suite.ts # Test suite utilities
│ └── index.ts # Framework exports
├── launcher/ # Network deployment tools
│ ├── kurtosis/ # Ethereum network launcher
│ ├── snowbridge/ # Relayer management
│ └── datahaven/ # DataHaven node management
├── generated/ # Generated types
│ ├── wagmi/ # Contract bindings
│ └── polkadot-api/ # Runtime types
└── docs/ # Testing documentation
├── E2E_TESTING_GUIDE.md
└── E2E_FRAMEWORK_OVERVIEW.md
```
## Test Suites
- **contracts.test.ts**: Contract deployment and configuration validation
- **cross-chain.test.ts**: Cross-chain message passing between Ethereum and DataHaven
- **datahaven-substrate.test.ts**: Block production, finalization, and consensus
- **ethereum-basic.test.ts**: Ethereum network health and basic functionality
- **native-token-transfer.test.ts**: Cross-chain token transfers via Snowbridge
- **rewards-message.test.ts**: Validator reward distribution from Ethereum to DataHaven
- **validator-set-update.test.ts**: Dynamic validator registration/deregistration via EigenLayer
Run individual suites:
```bash
bun test suites/rewards-message.test.ts
bun test suites/native-token-transfer.test.ts
bun test suites/validator-set-update.test.ts
```
2025-04-08 15:42:45 +00:00
## Further Information
2025-10-06 16:12:55 +00:00
- [Kurtosis ](https://docs.kurtosis.com/ ): Ethereum network orchestration
- [Zombienet ](https://paritytech.github.io/zombienet/ ): Polkadot-SDK network testing
- [Bun ](https://bun.sh/ ): TypeScript runtime and tooling
- [Foundry ](https://book.getfoundry.sh/ ): Solidity development framework
- [Polkadot-API ](https://papi.how/ ): Type-safe Substrate interactions
