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

Cover transaction manager with additional test cases #561

Closed
dshulyak opened this issue Jan 22, 2018 · 5 comments
Closed

Cover transaction manager with additional test cases #561

dshulyak opened this issue Jan 22, 2018 · 5 comments

Comments

@dshulyak
Copy link
Contributor

dshulyak commented Jan 22, 2018

Problem

Transaction manager (txqueue_manager.go) should be covered with additional test cases to ensure that it won't get accidentally broken after next changes.

Test cases that are currently missing:

  1. Verify that gas value and gas price is not ignored if received from a user
  2. Verify that a transaction is signed as we expect it to be signed

Implementation

  1. We definitely need to have additional test case with gas and gas price defined by a user. Might be 2 different test cases or 1 with both values defined.
  2. Second part of the issue is about verifying that we are sending transaction that we are expecting to send. I was planning to prepare a Transaction with all expected values, sign it the same way we do in transaction manager, rlp encode and provide as an expected value to a mock.
@status-open-bounty
Copy link

status-open-bounty commented Jan 29, 2018

Balance: 0.000000 ETH
Tokens: SNT: 735.00
Contract address: 0xeac87f51dffc04f7ad6c5270537bc57e7df1055c
Network: Mainnet
Paid to: canercidam
Visit https://openbounty.status.im to learn more.

@canercidam
Copy link
Contributor

Here's what I have in mind:

  1. A transaction is object is initialized.
  2. Gas price is set to a non-nil value.
  3. Gas is set to a non-nil value larger than default value.
  4. Transaction is used by CompleteTransaction and an identical copy is signed externally.
  5. Transaction hashes are compared.

How does it sound? And the test function could be called TestCompletionValidity since it covers both of the behaviours.

@dshulyak
Copy link
Contributor Author

That's close but not exactly. For the second part, I was planning to have a piece of code that will be used for every test case that completes a transaction. This piece of code can use transaction as an input and will prepare mocks for geth rpc api. Take a look at setupTransactionPoolAPI in tests for transactions manager

@canercidam
Copy link
Contributor

Ah okay, I see what you mean now. I'll start getting a PR ready in a bit.

@canercidam
Copy link
Contributor

@dshulyak I don't believe I solved it the way you imagined but this looked like the best way to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants