F/consumer rewards e2e

[maurolacy]

Adds rewards generation e2e test.

This first adapts / fixes the existing e2e tests to work with the new multi-contract setup.

Uses a sub-module to build the ibcsim-bcd container from the babylon-sdk reference; which is something that can clearly be improved. Perhaps in a follow-up?

Also, there are some (unrelated to staking integration) e2e tests that are failing. Commented them out in the test-e2e Makefile target. Sorted out this target so that is both up-to-date and depending on other existing targets, for robustness.
CI should use these targets as well. Perhaps in a follow-up?

[SebastianElvis]

The test lgtm, great work! Only comment is about whether to use submodule or git clone for getting babylon-sdk repo. Also CI failed though

[SebastianElvis]

Btw, shall we create a Github issue for moving the entire e2e-run-bcd-consumer-integration-test CI to babylon-sdk repo?

[maurolacy]

Btw, shall we create a Github issue for moving the entire e2e-run-bcd-consumer-integration-test CI to babylon-sdk repo?

We should, but sadly there are dependencies with babylon. The slashing tests, and in particular, the cascaded slashing ones, depend on babylon.

So, we should IMO duplicate (or better, replicate) the test setup in the babylon-sdk repo, for tests that are either independent of babylon, or in which babylon can be mocked or simulated. This is non-trivial, but can be done.

Also, writing more low-level unit tests for specific functionality, instead of comprehensive high-level e2e tests for it is a good idea, and something that we should try to incorporate.
By example, I could have unit-tested the rewards generation method in babylon-sdk, pretty much independently of all else. And then, I could perhaps have tested the contract -> sdk interaction somehow (by example, by making a test (gated under admin) entry point in the contract, to send the generate rewards custom message).

Unit tests in particular are relatively easy to write, and will give us more confidence (and a faster release cycle?) than writing complex e2e tests.

WDYT? Will document all this in the dev experience improvement issue, in any case.

[SebastianElvis]

Lgtm after replacing submodule with git clone 👍 great work on bumping contract setup

[SebastianElvis]

So, we should IMO duplicate (or better, replicate) the test setup in the babylon-sdk repo, for tests that are either independent of babylon, or in which babylon can be mocked or simulated. This is non-trivial, but can be done.

Agreed, I think babylon-sdk will need to replicate the setup of babylon e2e test setup, so that babylon repo focuses on testing itself whereas the sdk repo tests the integration e2e.

Also, writing more low-level unit tests for specific functionality, instead of comprehensive high-level e2e tests for it is a good idea, and something that we should try to incorporate.
By example, I could have unit-tested the rewards generation method in babylon-sdk, pretty much independently of all else. And then, I could perhaps have tested the contract -> sdk interaction somehow (by example, by making a test (gated under admin) entry point in the contract, to send the generate rewards custom message).
Unit tests in particular are relatively easy to write, and will give us more confidence (and a faster release cycle?) than writing complex e2e tests.

Also agreed. For example, the reward generation can be tested solely on the babylon-sdk side. Have you tried to use https://github.com/babylonlabs-io/babylon-sdk/tree/main/tests/e2e and the admin accounts for testing this?

[maurolacy]

Have you tried to use https://github.com/babylonlabs-io/babylon-sdk/tree/main/tests/e2e and the admin accounts for testing this?

That was my original plan, but I've spent so much time on this already, that I propose we left that as a follow-up issue / as part of https://github.com/babylonlabs-io/pm/issues/118.