-
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
x/auth: turn sign --validate-signatures into a standalone command #6108
x/auth: turn sign --validate-signatures into a standalone command #6108
Conversation
Codecov Report
@@ Coverage Diff @@
## master #6108 +/- ##
==========================================
+ Coverage 54.64% 54.83% +0.18%
==========================================
Files 443 439 -4
Lines 26655 26492 -163
==========================================
- Hits 14566 14527 -39
+ Misses 11092 10968 -124
Partials 997 997 |
4f6e86c
to
e45f99e
Compare
Now is a good moment to add a test for the Validate, should not be a difficult one with a hardcoded signature in the 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.
utACK
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.
Actually, we should add a test for this.
Yeah l second that. Would be great to leverage the new modular integration tests we have to cover this |
@alexanderbez @aaronc please have a look at 3644ad0, I'd appreciate feedback |
@alessio l think that approach makes sense 👍 |
a2e2f23
to
86517f9
Compare
--validate-signatures should not be a flag of the sign command as the operation performed (transaction signatures verification) is logically distinct. cli_test is and has always been an horrible name for package directory as it's very much Go anti-idiomatic - _test is the suffix used by test packages, not directories. Plus, CLI test cases can and should live alongside other testcases that don't require binaries to be built beforehand. Thus: x/module/client/cli_test/*.go -> x/module/client/cli/ Test files that require sim{cli,d} shall be tagged with // +build cli_test With regard to cli test auxiliary functions, they should live in: x/module/client/testutil/
64409d0
to
9586d6f
Compare
@alexanderbez bump |
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.
utACK
…smos#6108) --validate-signatures should not be a flag of the sign command as the operation performed (transaction signatures verification) is logically distinct. cli_test is and has always been an horrible name for package directory as it's very much Go anti-idiomatic - _test is the suffix used by test packages, not directories. Plus, CLI test cases can and should live alongside other testcases that don't require binaries to be built beforehand. Thus: x/module/client/cli_test/*.go -> x/module/client/cli/ Test files that require sim{cli,d} shall be tagged with // +build cli_test With regard to cli test auxiliary functions, they should live in: x/module/client/testutil/ Co-authored-by: Alexander Bezobchuk <alexanderbez@users.noreply.github.com>
--validate-signatures should not be a flag of the sign command
as the operation performed (transaction signatures verification)
is logically distinct.
cli_test is and has always been an horrible name for package
directory as it's very much Go anti-idiomatic - _test is the
suffix used by test packages, not directories. Plus, CLI test
cases can and should live alongside other testcases that don't
require binaries to be built beforehand. Thus:
x/module/client/cli_test/*.go -> x/module/client/cli/
Test files that require sim{cli,d} shall be tagged with // +build cli_test
With regard to cli test auxiliary functions, they should live in:
x/module/client/testutil/
For contributor use:
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerFor admin use:
WIP
,R4R
,docs
, etc)