Skip to content

Latest commit

 

History

History
48 lines (30 loc) · 3.01 KB

modifying-integration-tests.md

File metadata and controls

48 lines (30 loc) · 3.01 KB
Raw

Modifying the integration tests

This document is a short guide on how to add new integration tests.

Before starting you should read the entire design and spec document sets. As well as run the environment setup

Basic structure

The integration tests build and launch a docker container with an Ethereum chain, a 3 validator Cosmos chain running the Gravity bridge, and a 'test runner'.

The test runner is a single rust binary that coordinates the actual test logic, as well as spawns the Orchestrators and relayers.

The Ethereum backend for this test changes depending on which flow is being run.

A local Geth instance, with it's version defined in the dockerfile and it's parameters defined in the ETHGenesis.json

Or a HardHat instance that is actually launched from the Solidity tools folder and configured with the hardhat.config.ts.

Geth is chosen for nearly all tests. HardHat backed tests require an Alchemy API key so that they may test using production Ethereum data.

Exactly what test uses what Ethereum backend is decided in run-testnet.sh

Both Ethereum backends are configured to deposit tokens into a hardcoded address in the test runner. This address is also the deposit destination for the contract-deployer.ts when it creates some test ERC20 contracts.

The test runner module contains some logic for running the contract deployer and parsing the resulting ERC20 and Gravity.sol contract addresses. This is all done before we get into starting the actual tests logic.

Chain Upgrades

It is possible to simulate the Gravity Bridge chain going through an upgrade by using run-upgrade-test.sh. Pass a version like v1.4.3-beta and the test will download the given version of gravity from the Gravity-Bridge releases page, execute several of the integration tests to generate data. Then an upgrade gov proposal will execute and halt the chain, followed by the current chain code executing the same set of tests on the new binary.

Adding tests

In order to add a new test define a new test_type environmental variable in the test runners main.rs file from there you can create a new file containing the test logic templated off of the various existing examples.

The happy_path_test for example uses several repeatable utility functions to

  • start the orchestrators (with integrated relaying turned on)
  • generate keys for test users
  • deposit ERC20 tokens for those test users
  • test validator set updates

Every test should perform some action and then meticulously verify that it actually took place. It is especially important to go off the happy path and ensure correct functionality.