-
Notifications
You must be signed in to change notification settings - Fork 30
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
Improve Test Coverage for packages/web3/src/transaction
#462
Conversation
const validSignature = '78471e7c97e558c98ac307ef699ed535ece319102fc69ea416dbb44fbb3cbf9c42dbfbf4ce73eb68c5e0d66122eb25d2ebe1cf9e37ef4c4f4e7a2ed35de141bc' | ||
|
||
it('should handle different key types', () => { | ||
const ec = new EC.ec('secp256k1') |
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.
We can use PrivateKeyWallet.Random
to generate key pair.
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.
Ok I will implement this
@@ -46,4 +46,117 @@ describe('transaction', function () { | |||
const signature = transactionSign(txHash, privateKey) | |||
expect(transactionVerifySignature(txHash, publicKey, signature)).toEqual(true) | |||
}) | |||
|
|||
describe('transactionVerifySignature additional tests', () => { | |||
const validTxHash = '8fc5f0d120b730f97f6cea5f02ae4a6ee7bf451d9261c623ea69d85e870201d2' |
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.
Maybe we can
- Use
randomTxId()
function to create avalidTxId
- Create
validPubKey
usingPrivateKeyWallet.Random
- Generate the
validSignature
So we don't need to hardcode value here
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.
Ok sure. Thanks
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.
since I can't find a randomTxId() function, I actually don't know if there is a randomTxId() function somewhere. Hope I can create my own generateRandomTxId() function to achieve a good implementation
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.
Its in import { randomTxId } from '../contract'
.
try { | ||
const signature = transactionSign(validTxHash, invalidKey) | ||
// If no error thrown, the signature should fail verification | ||
expect(transactionVerifySignature(validTxHash, validPubKey, signature)).toBeFalsy() |
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.
Are there two possible outcomes?
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.
this is overly complex, It will always throw an error. I will be providing a correct implementation
const keyPair = ec.genKeyPair() | ||
const validPrivateKey = keyPair.getPrivate().toString('hex') | ||
|
||
try { |
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.
In all the places where we have the pattern of
try {
verify something
} catch (e) {
error is ok
}
Shall we be explicit about the outcome? Either we should expect an error or we the condition of the verification should match.
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.
ok
const fromAccount = await signer1.getSelectedAccount() | ||
const toAccount = await signer2.getSelectedAccount() | ||
describe('transaction confirmation', () => { | ||
let originalProvider: any |
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.
Question: What's the benefit of using originalProvider
compared to before?
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.
my adding originalProvider was unnecessary, I will have to change my implementations
|
||
describe('transaction utils', () => { | ||
beforeAll(() => { | ||
web3.setCurrentNodeProvider('http://127.0.0.1:22973', undefined, fetch) | ||
}) | ||
|
||
it('should calculate the group of transfer transaction', async () => { |
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.
Why do we remove some of the existing tests?
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.
when I tried testing the file all the test failed. came to the realization that I needed to connect to the Alephium devnet and that has been a strucgle
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.
I will love your assistance on how to successfully connect to the devnet
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.
You can run the devnet by running docker-compose up -d
under the docker
directory. After that the test case should be able to connect to devnet.
@@ -2184,4 +2184,4 @@ export class Api<SecurityDataType extends unknown> extends HttpClient<SecurityDa | |||
...params | |||
}).then(convertHttpResponse) | |||
} | |||
} |
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.
The diff in this file will fail the CI pipeline.
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.
this was a mistake
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.
I noticed the changes and tried correcting it back to how it initially was
web3.setCurrentNodeProvider(mockProvider as any) | ||
|
||
try { | ||
await waitForTxConfirmation('test-tx-id', 1, 10) |
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.
I think its better to use expect(....).toThrowError
since otherwise the test case would pass if waitForTxConfirmation
is executed successfully.
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.
ok I will implement that
|
||
}) | ||
|
||
describe('transaction types', () => { |
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.
I am unsure about the value of "transaction types" tests, since it is verifying the value of an object field we just set, no logic is involved. WDYT?
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.
You're right - the 'transaction types' tests aren't testing any actual logic since they're just verifying object fields. I will remove these tests and focus on testing the core functionality in utils.ts.
expect(transactionVerifySignature(txHash, pubKey, txSig)).toEqual(true) | ||
expect(transactionVerifySignature(txHash, pubKey, unnormalizedSig)).toEqual(false) | ||
expect(transactionVerifySignature(txHash, pubKey, wrongSig)).toEqual(false) | ||
const testWallet = PrivateKeyWallet.Random() |
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.
Please run npm run lint -- --fix
to fix all the formatting in the code.
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.
ok
expect(transactionVerifySignature(testTxHash, testWallet.publicKey, testSignature)).toEqual(true) | ||
}) | ||
|
||
describe('transactionVerifySignature validation', () => { |
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.
Q: Shall we have a nested describe
here? The should sign and verify signature
test above also test the transactionVerifySignature
function.
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.
sure. I will implement that right away
it('should correctly identify different transaction statuses', () => { | ||
const confirmedTx: node.TxStatus = { | ||
type: 'Confirmed', | ||
blockHash: '1234', | ||
txIndex: 0, | ||
chainConfirmations: 1, | ||
fromGroupConfirmations: 1, | ||
toGroupConfirmations: 1 | ||
} | ||
|
||
const mempoolTx: node.TxStatus = { | ||
type: 'MemPooled' | ||
} | ||
|
||
if (confirmedTx.type === 'Confirmed') { | ||
expect(confirmedTx.chainConfirmations).toBeDefined() | ||
expect(confirmedTx.blockHash).toBeDefined() | ||
} | ||
|
||
if (mempoolTx.type === 'MemPooled') { | ||
expect(Object.keys(mempoolTx).length).toBe(1) | ||
} | ||
}) |
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.
What is the goal of this test? As it rather tests the js/ts ability of Dynamic Object Creation and Structural Typing. Also if confirmedTx.type === 'Confirmed'
and mempoolTx.type === 'MemPooled'
do not pass, the assertions are not executed.
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.
let me remove that right away
hello @polarker I noticed you just closed my pr with unmerged commits. please what's going on |
@polarker I've worked on all the changes requested by the reviewers but I'm wondering why this is closed |
Hi, we’ve closed the PRs that we believe have a low likelihood of being merged. Rewards will be discussed and distributed through OD's platform. |
@polarker so Is there going to be remuneration for the work I have done? |
Title: Enhance Test Coverage for Transaction Package
Description:
Enhanced test coverage for packages/web3/src/transaction focusing on:
sign-verify.ts:
utils.ts:
All tests passing with improved code coverage.
Related issue: #456