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

Cleanup Baseapp tests #1579

Merged
merged 2 commits into from
Jul 7, 2018
Merged

Cleanup Baseapp tests #1579

merged 2 commits into from
Jul 7, 2018

Conversation

ebuchman
Copy link
Member

@ebuchman ebuchman commented Jul 6, 2018

Working on #1556

Will also likely address #1120 and replace some of #1172

  • Updated all relevant documentation in docs
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGELOG.md
  • Updated Gaia/Examples
  • Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)
  • Added appropriate labels to PR (ex. wip, ready-for-review, docs)

@codecov
Copy link

codecov bot commented Jul 6, 2018

Codecov Report

Merging #1579 into develop will increase coverage by 0.34%.
The diff coverage is 85.71%.

@@             Coverage Diff             @@
##           develop    #1579      +/-   ##
===========================================
+ Coverage    64.18%   64.53%   +0.34%     
===========================================
  Files          122      122              
  Lines         6674     6682       +8     
===========================================
+ Hits          4284     4312      +28     
+ Misses        2145     2125      -20     
  Partials       245      245

@ebuchman ebuchman changed the title WIP: Cleanup Baseapp tests Cleanup Baseapp tests Jul 7, 2018
@ebuchman
Copy link
Member Author

ebuchman commented Jul 7, 2018

Ok, this is ready aside from the changes to not run msg handlers on check tx.

It involved some fixes to the baseapp.

@ebuchman
Copy link
Member Author

ebuchman commented Jul 7, 2018

Should I rebase/squash?

@@ -36,7 +36,7 @@ var isAlpha = regexp.MustCompile(`^[a-zA-Z]+$`).MatchString
// AddRoute - TODO add description
func (rtr *router) AddRoute(r string, h sdk.Handler) Router {
if !isAlpha(r) {
panic("route expressions can only contain alphanumeric characters")
panic("route expressions can only contain alphabet characters")
Copy link
Contributor

@ValarDragon ValarDragon Jul 7, 2018

Choose a reason for hiding this comment

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

Good catch! However I think the regex not allowing numerics is the bug here, not the error message being mismatched. I think there are conceivable reasons for wanting numbers in routers.

Copy link
Member Author

Choose a reason for hiding this comment

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

Let's open a new issue for this

@@ -270,12 +290,10 @@ type testTx struct {

const msgType2 = "testTx"
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add a comment here saying that the point of this is that its a sample message that can fail ValidateBasic?

return
})

tx := testTx{13}
Copy link
Contributor

Choose a reason for hiding this comment

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

I found the 13 here confusing. (Took me a bit to remember where it came from) Maybe we should change testTx from taking in a number to just taking in a bool for whether or not to fail.

@ebuchman ebuchman force-pushed the bucky/baseapp-tests branch 2 times, most recently from fb3e7b1 to 31a1db9 Compare July 7, 2018 17:28
@ebuchman
Copy link
Member Author

ebuchman commented Jul 7, 2018

@ValarDragon thanks for initial review. I rebased on develop and squashed it down to 2 commits. I think some of your comments were addressed in later commits

@ebuchman
Copy link
Member Author

ebuchman commented Jul 7, 2018

It should probably just be one commit

@ebuchman ebuchman force-pushed the bucky/baseapp-tests branch from 31a1db9 to fe7ae11 Compare July 7, 2018 17:32
@ebuchman
Copy link
Member Author

ebuchman commented Jul 7, 2018

Ok squash down to one commit.

Let's get this merged - @cwgoes could use review on the changes to runTx for handling out-of-gas.

I'll work on #1120 in a separate PR.

@@ -534,53 +538,74 @@ func (app *BaseApp) runTx(mode runTxMode, txBytes []byte, tx sdk.Tx) (result sdk
ctx = ctx.WithMultiStore(msCache)
}

finalResult := sdk.Result{}
// accumulate results
var logs []string
Copy link
Contributor

@ValarDragon ValarDragon Jul 7, 2018

Choose a reason for hiding this comment

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

Can you do make([]string, 0, len(msgs), saves overhead due to expanding the slice.

* simplify mock tx type, msgs, and handlers
* remove dependencies on auth and bank
* dedup with setupBaseApp
* lots of comments and cleanup
* fixes where we weren't checking results
* use some table driven tests
* remove TestValidatorChange - its not testing anything since baseapp
doesnt track validator changes
* prepare for CheckTx only running the AnteHandler
* fix runTx gas handling and add more tests
* new tests for multi-msgs
ctx = app.checkState.ctx.WithTxBytes(txBytes)
} else {
ctx = app.deliverState.ctx.WithTxBytes(txBytes)
ctx = ctx.WithSigningValidators(app.signedValidators)
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe I'm unclear on what the purpose of simulate is, but why doesn't it get access to any of the app's signed validators? (How can it simulate how a slashing or staking tx will happen w/o this?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeh good question. The problem is that information is only supplied by BeginBlock, and when we're simulating, we don't know what the next BeginBlock will look like ...

Copy link
Contributor

Choose a reason for hiding this comment

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

Hrmm. Would it make sense to have an option where its simulated as the last tx in the last known block (for things that depend on headers / validator set), and an option for on the next block (for conceivable things that depend on the exact block height)? This discussion should probably be carried out in a separate issue though

Copy link
Contributor

Choose a reason for hiding this comment

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

Could be useful, although that seems like a rare case - all slashing logic related to signing (downtime / evidence) happens in a BeginBlock handler, not in transactions.

Copy link
Contributor

@cwgoes cwgoes left a comment

Choose a reason for hiding this comment

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

Baseapp changes LGTM, a few future suggestions but nothing that needs to block merge.

// accumulate results
logs := make([]string, 0, len(msgs))
var data []byte // NOTE: we just append them all (?!)
var tags sdk.Tags // also just append them all
Copy link
Contributor

Choose a reason for hiding this comment

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

tendermint/tendermint#1803 will provide a better option here

}
if !newCtx.IsZero() {
ctx = newCtx
}
gasWanted = anteResult.GasWanted
Copy link
Contributor

Choose a reason for hiding this comment

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

Presently the ante handler returns an empty sdk.Result{} - did we want it to set GasWanted (to tx.Fee.Gas presumably)?

Copy link
Member Author

Choose a reason for hiding this comment

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

Believe so

ctx = app.checkState.ctx.WithTxBytes(txBytes)
} else {
ctx = app.deliverState.ctx.WithTxBytes(txBytes)
ctx = ctx.WithSigningValidators(app.signedValidators)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could be useful, although that seems like a rare case - all slashing logic related to signing (downtime / evidence) happens in a BeginBlock handler, not in transactions.

for i, msg := range msgs {
// accumulate results
logs := make([]string, 0, len(msgs))
var data []byte // NOTE: we just append them all (?!)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm still not clear what exactly data and logs are for, and what the difference between them is intended to be.

At the moment, I think the SDK uses data in one instance to return a proposal ID (in governance), and doesn't use logs at all. The created proposal ID could just as easily be returned as a tag (probably will be anyways, for later querying) - maybe we can simplify ABCI or what parts of ABCI we use?

Copy link
Member Author

Choose a reason for hiding this comment

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

log is intended for non-deterministic output from the app. There is some sense that it would be used to pipe the apps actual logs back to tendermint but I don't think anyone has ever done that.

data is a deterministic result - we don't really use it AFAIK, so it probably could just be absorbed into tags, but it might be worth keeping for simple apps that want a definitive return value

@ebuchman ebuchman merged commit 988614e into develop Jul 7, 2018
@ebuchman ebuchman deleted the bucky/baseapp-tests branch July 7, 2018 23:04
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