-
-
Notifications
You must be signed in to change notification settings - Fork 226
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
Add encode data tests #164
Conversation
26e0e45
to
a8b29eb
Compare
9496871
to
ea3dcbb
Compare
ea3dcbb
to
37ee5ab
Compare
37ee5ab
to
26982ac
Compare
082f3f5
to
b41746f
Compare
The function `TypedDataUtils.encodeData` has been thoroughly tested with all novel inputs I could think of. Each supported version (V3 and V4) have been tested independently with each input. There are also tests for each input that should have an identical encoding between V3 and V4, and each that should have non-matching signatures. The structure of the tests is explained in a large inline comment at the start of the `describe` block for `TypedDataUtils.encodeData`. The `encodeData` assertions that accompanied the signature tests have been deleted, as they're now redundant.
b41746f
to
6e0a88d
Compare
This PR has been updated with more inline comments explaining what the tests are for. |
// Reassigned to silence "no-loop-func" ESLint rule | ||
// It was complaining because it saw that `it` and `expect` as "modified variables from the outer scope" | ||
// which can be dangerous to reference in a loop. But they aren't modified in this case, just invoked. | ||
const _expect = expect; |
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 really wish there was some way to silence this false positive. I didn't want to disable the rule for the whole file because it's genuinely useful still, but this is irritating.
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.
Finished a first pass. Overall looks good. I left some inline change requests.
I'm going to do one more pass to confirm that the table is fully covered, and consider whether the inputs are exhaustive or not. Then we should be done here!
), | ||
]; | ||
|
||
describe('TypedDataUtils.encodeData', 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.
Why are we not using arrow functions for the callbacks in this test suite? mocha
hangover?
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.
Ah, right 😅
I was just following existing conventions (I think?). Probably better to use arrow functions, but maybe we can do this in one pass later on.
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.
LGTM!
The function
TypedDataUtils.encodeData
has been thoroughly tested with all novel inputs I could think of. Each supported version (V3 and V4) have been tested independently with each input. There are also tests for each input that should have an identical encoding between V3 and V4, and each that should have non-matching signatures.The structure of the tests is explained in a large inline comment at the start of the
describe
block forTypedDataUtils.encodeData
.The
encodeData
assertions that accompanied the signature tests have been deleted, as they're now redundant.