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(halo/evmstaking2): unit tests for unhappy paths #2591

Merged
merged 7 commits into from
Dec 3, 2024

Conversation

chmllr
Copy link
Contributor

@chmllr chmllr commented Nov 29, 2024

More unit tests for unhappy paths.

issue: #2525

@@ -88,18 +88,112 @@ func TestInsertAndDeleteEVMEvents(t *testing.T) {
}
}

func TestHappyPathDelivery(t *testing.T) {
func TestDeliveryWithBrokenServer(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Need godocs for all tests

Copy link
Collaborator

Choose a reason for hiding this comment

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

we don't really do this for any tests in the code base. So not sure we can start a new convention simply in the middle of a PR review?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did some quick googling and it does not look like this convention is a thing, in general...

I think comments inside the test doing the "handholding" and explaining the steps are more useful, aren't they? If the godoc would contain all these details instead, you'd still need to do mental work by mapping the docs to the actual code. But if we remove the details, then the test name is already explaining the high level idea, doesn't it?

Copy link
Contributor

@kc1116 kc1116 Dec 2, 2024

Choose a reason for hiding this comment

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

we don't really do this for any tests in the code base. So not sure we can start a new convention simply in the middle of a PR review?

I think this is fine starting good standards as we go along, especially in small PR's. wydt ?

I did some quick googling and it does not look like this convention is a thing, in general...

I think comments inside the test doing the "handholding" and explaining the steps are more useful, aren't they? If the godoc would contain all these details instead, you'd still need to do mental work by mapping the docs to the actual code. But if we remove the details, then the test name is already explaining the high level idea, doesn't it?

Brief godoc that concisely describes the test and expected behavior is very useful. Example geth. That way without any context a dev can see what the test does, just looking at the code is not enough. I dont think there is any cost to adding godocs for all tests (atleast the more involved ones) and all exported funcs.

@chmllr chmllr changed the title feat(halo/evmstaking2) more unit tests for unhappy paths feat(halo/evmstaking2) unit tests for unhappy paths Nov 29, 2024
@chmllr chmllr marked this pull request as ready for review November 29, 2024 13:37
@chmllr chmllr requested a review from corverroos as a code owner November 29, 2024 13:37

for _, event := range events {
err := keeper.parseAndDeliver(ctx, &event)
require.True(t, strings.Contains(err.Error(), sServer.err.Error()))
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Incorrect syntax usage of require , update all usages.

Suggested change
require.True(t, strings.Contains(err.Error(), sServer.err.Error()))
require.Error(t, err)
require.Contains(t, err.Error(),"create validator: pubkey to cosmos")

Using require.Error and require.Contains is preferred as it provides clearer intent, better failure messages, and avoids potential panics if err is nil. It also aligns with idiomatic testing practices for improved readability and debugging.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice! Thanks!

@@ -240,6 +240,10 @@ func (k Keeper) deliverDelegate(ctx context.Context, ev *bindings.StakingDelegat
return errors.New("validator does not exist", "validator", valAddr.String())
}

if ev.Amount == nil {
Copy link
Collaborator

Choose a reason for hiding this comment

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

lets add a "verifyStakingDelegatefunction. Also, we can rename theev` variable, it was copy paste bug.

@@ -88,18 +88,112 @@ func TestInsertAndDeleteEVMEvents(t *testing.T) {
}
}

func TestHappyPathDelivery(t *testing.T) {
func TestDeliveryWithBrokenServer(t *testing.T) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

we don't really do this for any tests in the code base. So not sure we can start a new convention simply in the middle of a PR review?

@chmllr chmllr changed the title feat(halo/evmstaking2) unit tests for unhappy paths feat(halo/evmstaking2): unit tests for unhappy paths Dec 2, 2024
@@ -1,3 +1,4 @@
//go:generate mockgen -source ./interfaces.go -package testutil -destination ../testutil/mock_interfaces.go
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a new command to the Makefile where we can put all the generate mock commands. Also mocks tend to go in a mocks dir so that the import is more explicit mocks.MockStakingMsgServer

.PHONY: generate-mocks
generate-mocks:
	mockgen -source ./halo/evmstaking2/types/interfaces.go -package mocks -destination halo/evmstaking2/mocks/interfaces.go/mocks.go

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would leave this out here and instead create one PR doing this for all other tests later.

Copy link
Contributor

@kc1116 kc1116 left a comment

Choose a reason for hiding this comment

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

LGTM, make sure to add the command to the makefile and move the mocks to a mocks dir not testutil.

@chmllr chmllr merged commit 3b2f469 into main Dec 3, 2024
19 checks passed
@chmllr chmllr deleted the chmllr/valsync-part-9 branch December 3, 2024 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants