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

Table-Driven Bank Module Unit Tests #1764

Merged
merged 2 commits into from
Jul 20, 2018
Merged

Conversation

alexanderbez
Copy link
Contributor

@alexanderbez alexanderbez commented Jul 19, 2018

Changes

  • Update x/bank app unit tests to be (mostly) table-driven
  • Cleaned up existing unit tests

closes: #1546


  • Updated all relevant documentation (docs/)
  • Updated all relevant code comments
  • Wrote tests
  • Updated CHANGELOG.md
  • Updated cmd/gaia and examples/

For Admin Use:

  • Added appropriate labels to PR (ex. wip, ready-for-review, docs)
  • Reviewers Assigned
  • Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

@alexanderbez alexanderbez changed the title Update bank app unit tests to be table-driven Table-Driven Bank Module Unit Tests Jul 19, 2018
@alexanderbez alexanderbez force-pushed the bez/1546-bank-table-driven-tests branch from 81c86df to 49b7a4a Compare July 19, 2018 18:39
privKeys: []crypto.PrivKey{priv1},
},
{
addr: addr1,
Copy link
Contributor

Choose a reason for hiding this comment

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

Any particular reason you have a switch case to check the expected state transition, instead of having a different field in the appTestCase struct for expected outcome? Putting it in the appTestCase struct seems more optimal to me.

Copy link
Contributor Author

@alexanderbez alexanderbez Jul 19, 2018

Choose a reason for hiding this comment

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

You mean why do I leverage the mock#* calls? No particular reason. This was the original code and figured I'd leave it this way to leverage existing functionality. I can take a look at those function calls and put the require statements directly in here if that's what you'd prefer?

Copy link
Contributor

@ValarDragon ValarDragon Jul 19, 2018

Choose a reason for hiding this comment

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

No, I mean that the struct has a "simBlock" flag. When that is true, it runs a block, when its false, it tests that the expected action happened.

I think it would be easier if we had a list of expected address / coin amounts after running the tx, and we put those directly in the struct. this would mean adding a new struct type:
expectedAddressCoinAmount {Address, Coins} (better name probably exists)

and then adding to the appTestCase struct, an []expectedAddressCoinAmount and removing simBlock

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 see, yeah we can do that for sure 👍

@ebuchman
Copy link
Member

Can we do this without mock ?

@codecov
Copy link

codecov bot commented Jul 19, 2018

Codecov Report

❗ No coverage uploaded for pull request base (develop@f3a1290). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop    #1764   +/-   ##
==========================================
  Coverage           ?   62.77%           
==========================================
  Files              ?      122           
  Lines              ?     7125           
  Branches           ?        0           
==========================================
  Hits               ?     4473           
  Misses             ?     2390           
  Partials           ?      262

@alexanderbez
Copy link
Contributor Author

Yeah, I'll see if we can do this without mock @ebuchman 👍

@alexanderbez alexanderbez force-pushed the bez/1546-bank-table-driven-tests branch from a323a68 to 63ccb2c Compare July 20, 2018 13:31
@alexanderbez
Copy link
Contributor Author

alexanderbez commented Jul 20, 2018

@ValarDragon updated to address your concern.

@ebuchman I can remove the dependency on mock by simply copying that code. But I imagine we'd do that for the other modules as well. Would you like to move the test helpers/utils file with this logic out of mock?

Thoughts on moving those helpers to test/utils.go?

@alexanderbez alexanderbez removed the wip label Jul 20, 2018
@alexanderbez
Copy link
Contributor Author

I think the mock issue is left up to another PR. I think this is R4R 👍

Copy link
Contributor

@ValarDragon ValarDragon left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for doing this!

One minor comment re order of expected balance

privKeys: []crypto.PrivKey{priv1, priv4},
expectedBalances: []expectedBalance{
expectedBalance{addr1, sdk.Coins{sdk.NewCoin("foocoin", 32)}},
expectedBalance{addr4, sdk.Coins{sdk.NewCoin("foocoin", 32)}},
Copy link
Contributor

Choose a reason for hiding this comment

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

minor nitpick, can the addresses be sorted? i.e. addr1, addr2, addr3 then 4

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure! I had them originally as they were implemented, but I can certainly order them by address.

mock.CheckBalance(t, mapp, addr2, sdk.Coins{sdk.NewCoin("foocoin", 52)})
mock.CheckBalance(t, mapp, addr3, sdk.Coins{sdk.NewCoin("foocoin", 10)})
for _, eb := range tc.expectedBalances {
mock.CheckBalance(t, mapp, eb.addr, eb.coins)
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be left for a seperate PR, but perhaps mock.CheckBalance should take in a message parameter, so that we can have error messages as described in https://github.com/cosmos/cosmos-sdk/blob/develop/CONTRIBUTING.md#testing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Definitely worthy for another PR :-)

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.

utACK, agreed on removing mock, needs to be discussed.

@cwgoes cwgoes merged commit f437f36 into develop Jul 20, 2018
@cwgoes cwgoes deleted the bez/1546-bank-table-driven-tests branch July 20, 2018 22:46
chillyvee pushed a commit to chillyvee/cosmos-sdk that referenced this pull request Mar 1, 2024
* add queries and structure for e2e slashing test

* use the same menemonic for all jailed validators

* add `Delegations` to jailed validator

* fix the jailed validator init

* add slashingShares globar const

* fix duplicated import

* fix staking UnbondingTime

* use httpGet help method

* remove staking genesis params

* remove unused code

* add error to logs

* add more explicit variable name for jailed validator account
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

x/bank: Switch MsgSend tests to be table driven
4 participants