-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Make integration test suites reusable by apps #6711
Conversation
Codecov Report
@@ Coverage Diff @@
## master #6711 +/- ##
==========================================
+ Coverage 58.89% 59.70% +0.81%
==========================================
Files 585 595 +10
Lines 32801 37315 +4514
==========================================
+ Hits 19318 22279 +2961
- Misses 11199 13057 +1858
+ Partials 2284 1979 -305
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just don't personally see the benefit to this approach. I don't want to block on my review, however. SDK developers at large should appropriately review this and merge if there is alignment.
For my team we are very interested in the efforts to make the test suites accessible for integration with the tests of our own modules. There is a lot of benefit from our perspective to ensuring that the application we have built on the SDK continues to support base behaviors correctly as new modules are added. This is especially important in cases such as a module that create extensions on BaseAccount. My view is that all of the features contained in the resulting app need to be fully exercised regardless of if they were inherited or directly implemented in order to achieve a comprehensive integration test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good from my end too. Pending lint and conflict fixes
x/bank/client/testutil/suite.go
Outdated
@@ -275,7 +272,7 @@ func (s *IntegrationTestSuite) TestNewSendTxCmd() { | |||
ctx := context.Background() | |||
ctx = context.WithValue(ctx, client.ClientContextKey, &clientCtx) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ineffassign
@@ -543,7 +543,7 @@ func (s *IntegrationTestSuite) TestNewWithdrawRewardsCmd() { | |||
ctx := context.Background() | |||
ctx = context.WithValue(ctx, client.ClientContextKey, &clientCtx) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ineffassign
How does what is contained in this PR aid in this regard? Is there a PR or code you can point me to that references this? Module CLI integration tests are self-contained and isolated. How does accessing, say x/bank integration test suite, help you test your module? I've stated above I'm very reluctant to merging this PR. |
Module CLI integration tests are not self-contained and isolated, they are running against simapp. Simapp is not what zone developers are deploying. I want to be able to run these integration test suites against the wired together app that I am building. I believe that is @iramiller's use case as well. I am actually in favor of still running these suites as unit tests scoped to their modules - I might update this PR to keep those in place. But I also want to be able to wire up these suites in Regen's code base to run against Regen's app. |
Indeed. I am interested in any changes that could be leveraged for exercising the built in SDK unit/integration type tests against my team's app. For reference when I tested the cli_tests from gaia (which required a great deal of tweaking to run in our environment) I encountered several errors where we had made changes that broke expected behavior. As a specific example we have patched our command flags to set some default/provide some structure that is appropriate for our use. During the run of the cli_tests it became clear that we had inadvertently wired a piece incorrectly. While our app behaved as expected an end user trying to follow SDK examples and use some of the extra flags would have found them to not work as expected. This experience has made me very aware that we have a significant number of crucial pieces in our system that are inherited from the SDK and that they are not entirely isolated and safe from accidental breakage. From my perspective this is very solvable with the simulations, unit, and related integration tests that exist today in the SDK so my hope is that we will see changes that make these more accessible to SDK consumers for comprehensive testing of their own apps. |
Ok, then maybe we have different definitions of self-contained. Just because a suite uses simapp, doesn't mean its not self-contained and isolated. e.g. x/bank CLI integration tests are running x/bank CLI commands and x/bank only -- it doesn't rely on anything else and runs in isolation from other modules integration test suites. |
I'm still not quite following @iramiller. How Gaia tests the CLI is radically broken, outdated, poorly designed, and most importantly, different than how we perform integration testing now (take a look at x/bank for example). |
My point was not that the specific implementation used in |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@aaronc is this still in path for stargate cc @clevinson |
I'd love that. Could you write the command to run a single test in this PR? If we have that, I'm approving this PR. |
@AmauryM , here is an example with a full log:
You can remove |
BTW, @alessio - it's possible to use only the
|
@robert-zaremba thanks, that works 👍 . I'm good with this. @atheeshp could you fix the conflicts? |
Just to reiterate, the main goal of this refactoring is so that other apps can run these integration test suites against their app instead of simapp. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Any further actions on this PR? @clevinson , @aaronc |
I'm going to move forward with merging this. It improves the testability of the SDK by apps and we will start leveraging this ASAP for additional QA in gaia, regen and other apps. @shahankhatch, someone on our team can walk you through using this in gaia |
This is a relatively small refactor of the work done so far on #6423 to make in-process integration tests easily reusable by apps.
For the existing test suites (bank, crisis and distribution) the following changes were made:
IntegrationTestSuite
intoclient/testutil/suite.go
filesNewIntegrationTestSuite
constructor to the suites which takes a singleConfig
parameterBefore we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes