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

test(08-wasm): added 'TestInitialize' using mockVM #4894

Merged
merged 9 commits into from
Oct 19, 2023

Conversation

srdtrk
Copy link
Member

@srdtrk srdtrk commented Oct 17, 2023

Description

This PR:

  • implements TestInitialize using mockVM
  • renames grandpaClientID to wasmClientID

closes: #4825

Commit Message / Changelog Entry

test(08-wasm): added 'TestInitialize' using mockVM

see the guidelines for commit messages. (view raw markdown for examples)


Before 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.

  • Targeted PR against correct branch (see CONTRIBUTING.md).
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/).
  • Added relevant godoc comments.
  • Provide a commit message to be used for the changelog entry in the PR description for review.
  • Re-reviewed Files changed in the Github PR explorer.
  • Review Codecov Report in the comment section below once CI passes.

@srdtrk srdtrk added testing Testing package and unit/integration tests 08-wasm labels Oct 17, 2023
Comment on lines 36 to 39
const (
tmClientID = "07-tendermint-0"
grandpaClientID = "08-wasm-0"
tmClientID = "07-tendermint-0"
wasmClientID = "08-wasm-0"
)
Copy link
Member Author

Choose a reason for hiding this comment

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

At one point, I was using grandpaClientID in my test (I'm not anymore). So I had renamed it to wasmClientID. I can revert this if requested.

Copy link
Member Author

Choose a reason for hiding this comment

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

reverted

Copy link
Member

Choose a reason for hiding this comment

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

Curious, how come you reverted? I think wasmClientID makes more sense, doesn't it?

Copy link
Member Author

Choose a reason for hiding this comment

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

It made this PR harder to review due to large diff. I want to make a new PR for this

Copy link
Member

@damiannolan damiannolan left a comment

Choose a reason for hiding this comment

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

Thanks @srdtrk, nice work. LGTM! 🙏

// tmConsensusStateData, err := suite.chainA.Codec.MarshalInterface(tmConsensusState)
// suite.Require().NoError(err)
func (suite *TypesTestSuite) TestInitialize() {
panicMsg := errors.New("panic in InstantiateFn")
Copy link
Member

Choose a reason for hiding this comment

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

I'm unsure if we should bother testing for a panic... what do you think? We should never have to handle a panic from the vm inside of our code, right? Aren't all panics caught here within the actual vm and propagated as errors?

Would probably simplify the test structure if we didn't have to include this, but either way test looks good!

Copy link
Member Author

Choose a reason for hiding this comment

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

Since wasm engine is an interface now, I think it should be in our scope to include basic tests that might break certain assumptions about wasmvm. Also, I'm not sure if they panic later again somewhere in their code

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd agree with Damian here. From what I can understand, the idea is to test that panics are propagated across the boundary (which might not be FFI like wasmvm)? I'm trying to understand the benefit of testing for this, especially given that wasmvm appears to translate em all into err's i.e if we plugged wasmvm here, it would fail.

W/e the case, happy to keep on this path if there's consensus!

Copy link
Member

Choose a reason for hiding this comment

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

cc. @chatton @charleenfei @colin-axner any thoughts/preference? I didn't implement panic tests in #4923 yet but if there's consensus to do it I will push an update.

I'd see more of an argument to testing for panics if we were actually recovering from them in client state methods, but we aren't, if a panic occurs across the api boundary here its just going to propagated to baseapp anyways.
I'd be happy to skip the panic tests as it simplifies the structure and is easier to read and maintain in the long run

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I guess the only benefit I see to implementing panic tests is making sure that there are no panic recoveries anywhere in the stack between callbackFn and 02-client cc. @damiannolan

Copy link
Contributor

@charleenfei charleenfei Oct 26, 2023

Choose a reason for hiding this comment

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

sorry late to this thread, but i told @damiannolan my thoughts in person (and in my original discussion on this topic with @srdtrk), agree with skipping panic tests.

Comment on lines 36 to 39
const (
tmClientID = "07-tendermint-0"
grandpaClientID = "08-wasm-0"
tmClientID = "07-tendermint-0"
wasmClientID = "08-wasm-0"
)
Copy link
Member

Choose a reason for hiding this comment

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

Curious, how come you reverted? I think wasmClientID makes more sense, doesn't it?

@@ -82,6 +82,9 @@ func (suite *TypesTestSuite) SetupWasmWithMockVM() {
suite.coordinator = ibctesting.NewCoordinator(suite.T(), 1)
suite.chainA = suite.coordinator.GetChain(ibctesting.GetChainID(1))

suite.ctx = suite.chainA.GetContext().WithBlockGasMeter(storetypes.NewInfiniteGasMeter())
suite.store = suite.chainA.App.GetIBCKeeper().ClientKeeper.ClientStore(suite.ctx, grandpaClientID)
Copy link
Member

Choose a reason for hiding this comment

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

I'd be in favour of switching var name or having another const DefaultWasmClientID or similar

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense, will be making another PR for this

@srdtrk srdtrk merged commit bcdceab into feat/wasm-clients Oct 19, 2023
61 checks passed
@srdtrk srdtrk deleted the serdar/issue#4825-wasm-TestInitialize branch October 19, 2023 09:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
08-wasm testing Testing package and unit/integration tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants