Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: LP integration tests #1720

Merged
merged 131 commits into from
Jun 13, 2024
Merged

Feat: LP integration tests #1720

merged 131 commits into from
Jun 13, 2024

Conversation

mustermeiszer
Copy link
Collaborator

@mustermeiszer mustermeiszer commented Feb 6, 2024

Description

Currently, we can only test EVM <> Substrate interactions in the UI/testnetworks. This is cumbersome and not reliable for testing changes both on the Substrate as also on the EVM side.
This PR enables to write real e2e tests for both codebases.

Changes and Descriptions

  • builds https:/centrifuge/liquidity-pools and returns all needed *.json files for creating contracts
  • provides an additional trait EvmEnv that provides interaction with EVM in the test codebase

How to test

  1. Install Foundry Forge CLI
  2. Run Tests
cargo test -p runtime-integration-tests 

If you encounter an error with an unset LP_SOL_SOURCES env var, the script did not build the solidity contracts in target/debug/build/runtime-integration-tests-*/out/liquidity-pools properly. Try removing all runtime-integration-tests directories in target/debug/build/ and runtime_integration_tests ones in target/debug/debs/. If that doesn't help, clear the entire target directory.

Checklist:

  • I have added Rust doc comments to structs, enums, traits and functions
  • I have made corresponding changes to the documentation
  • I have performed a self-review of my code
  • I have added tests that prove my fix is effective or that my feature works

Copy link
Contributor

@lemunozm lemunozm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really cool testing feature and added very clean! 🚀

Left some minor questions, suggestions and NITs. But everything is minor. Good job!

runtime/integration-tests/src/generic/cases/example.rs Outdated Show resolved Hide resolved
Comment on lines 21 to 38
/*
match Command::new("git")
.args(&["fetch", "--all", "--recurse-submodules=yes"])
.output()
{
Ok(o) if o.status.success() => {}
Ok(o) => {
println!(
"cargo:warning=Git fetch failed with: \n - status: {}\n -stderr: {}",
o.status,
String::from_utf8(o.stderr).expect("stderr is utf-8 encoded. qed.")
);
}
Err(err) => {
println!("cargo:warning=Failed to execute git command: {}", err);
}
}
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: Should this always be done, or is it expected the developer does this manually before running these tests?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. AFAICT, we should solve this via CI which regularly pulls the latest contracts

Copy link
Contributor

@lemunozm lemunozm Feb 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should solve this via CI which regularly pulls the latest contracts

One concern regarding this is that an update in liquidity-pools can break our CI. I suppose it is centrifuge-chain who should choose the commit used from liquidity-pools. When liquidity-pools is updated, then we should create a commit in centrifuge-chain just updating the dependency.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not 100% sure on the process here, tbh. @hieronx wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When liquidity-pools is updated, then we should create a commit in centrifuge-chain just updating the dependency.

I think this makes sense. Also because we probably want to be able to run the main tests against the release commit from liquidity pools (what is live now), but also want to be able to run the tests in a branch against a more recent development commit. Having the commit be chosen manually would make this possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the Liquidity Pools repo should include a CI which runs LP integration tests from Centrifuge Chain and notify Protocol / Centrifuge Chain repo when it is failing such that we know a breaking change has been introduced on the EVM side.

runtime/integration-tests/src/generic/envs/runtime_env.rs Outdated Show resolved Hide resolved
runtime/integration-tests/src/generic/envs/runtime_env.rs Outdated Show resolved Hide resolved
runtime/integration-tests/src/generic/cases/lp/mod.rs Outdated Show resolved Hide resolved
runtime/integration-tests/src/generic/cases/lp/mod.rs Outdated Show resolved Hide resolved
runtime/integration-tests/src/generic/envs/runtime_env.rs Outdated Show resolved Hide resolved
.gitmodules Outdated
[submodule "runtime/integration-tests/submodules/liquidity-pools"]
path = runtime/integration-tests/submodules/liquidity-pools
url = [email protected]:centrifuge/liquidity-pools.git
branch = feat/local-router
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually, we want to use the main branch here right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! Curious too about this

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feature branch for the local router we need for routing to local evm. Will be master once this is merged

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main branch can be used now. cc @wischli

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: Main branch cannot be used as the LocalRouter feat is required. We have been using the centrifuge-chain/release-v1.0 branch: centrifuge/liquidity-pools#260

@cdamian
Copy link
Contributor

cdamian commented Feb 12, 2024

Looks awesome so far @mustermeiszer! Thanks for taking care!

@wischli wischli added the I4-tests Test needs fixing or improving. label Feb 12, 2024
.to_str()
.expect("OsStr is utf-8. qed");

match Command::new("forge")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a small script for downloading a specific version of this or at least mention the version that is known to work. I guess we want to avoid having failures here by using a version that might behave differently.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, there definitely needs to be some improvement to this. Maybe it is sufficient to add forge install to our init.sh script for local development. For CI, forge is already installed manually. Eventually, there should be one codepath setting up requirements both for local development. as well as CI.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unsure how to proceed here. I think for now, erroring out if forge is not installed is fine, or should we install it during the build script - i mean locally in the build directory?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or should we install it during the build script - i mean locally in the build directory?

I think this is the best option. The script should fetch locally everything it needs to work properly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although compiling this implies compiling 900 crates 😅

let source = match parent {
"liquidity-pools" => {
println!(
"cargo:info=Build liquidity-pools Solidity contracts. Stored at {} ",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cargo:info doesn't seem to be supported.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using warning now. Maybe confusing, but I think helpful to know where they are stored, wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, let's keep the warning for now, I wanna re-run everything on this branch later on and I think I'll need these ^^

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe executing echo and printing the info message can work to avoid the warning?


/*
match Command::new("git")
.args(&["pull", "--all", "--recurse-submodules=yes"])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note - Locally, I had to run a git submodule update --init --recursive first.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want that in or should everybody pull the deps themselves?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, probably not. But I think we should adapt some of the comments/error messages to in this part.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @cdamian that we should modify the message.

Copy link
Contributor

@lemunozm lemunozm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First review pass. Looks pretty clean despite the amount of code in the PR 💯

Just some Nits and question. Nothing important. In my second round I wanted to review the cases. Hopefully today or tomorrow

Copy link
Contributor

@lemunozm lemunozm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Let's merge this beast!

@mustermeiszer mustermeiszer enabled auto-merge (squash) June 13, 2024 07:51
@lemunozm
Copy link
Contributor

@cdamian I think we need your approval to get this in 💪🏻

@mustermeiszer mustermeiszer merged commit 3b6a8c9 into main Jun 13, 2024
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I4-tests Test needs fixing or improving.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants