fix: Add tests for json-rpc-data and address to describe expected behaviour #2716
Conversation
|
I spent some time looking into this today, and have a reasonable grasp on what's going on. I just wanted to check whether my expectations around the behaviour are correct, so this PR only contains a couple of tests describing that behaviour. Don't expect anything to work, and don't take this as a full and complete set of tests for this behaviour! Thanks. |
jeffsmale90
force-pushed
the
fix/address_padding
branch
from
29b9ada
to
0ec3f30
Compare
|
If you have a look at the build, pretty much all of these tests currently fail, except for the first set where no byteLength parameter is passed, as in the current implementation, the byteLength parameter has no impact on the toString() result. |
There was a problem hiding this comment.
This looks good! If you implemented these changes I think it will give us a lot more confidence in our Data types. I think the biggest concern is all of the possible side affects this fix could cause. Let's hope our tests are robust enough to catch them!
One more thing to note that I realize as I was digging into the code for the Data constructor. It only allows a value of type string | Buffer, but we only validate against bigint. It might be worth adding extra validation? ¯_(ツ)_/¯
jeffsmale90
force-pushed
the
fix/address_padding
branch
from
f39c97d
to
36e1735
Compare
…on-rpc-data and address types
jeffsmale90
force-pushed
the
fix/address_padding
branch
2 times, most recently
from
4a2472a
to
c9b50bc
Compare
jeffsmale90
force-pushed
the
fix/address_padding
branch
from
c9b50bc
to
c99736f
Compare
|
There's plenty of opportunity to improve this - ie. I tested the performance impact of removing the weakmaps, and it's quite significant, but I wanted to fix the issue without changing too much, with the intention of addressing remaining problems when we rework this. |
jeffsmale90
changed the title
jeffsmale90
changed the title
Co-authored-by: Micaiah Reid <micaiahreid@gmail.com>
Co-authored-by: Micaiah Reid <micaiahreid@gmail.com>
Co-authored-by: Micaiah Reid <micaiahreid@gmail.com>
Co-authored-by: Micaiah Reid <micaiahreid@gmail.com>
… and explain the cases in getExpectedString
|
Lucky you suggested the change to use getExpectedString - because it didn't truncate properly! The reason I had a couple of special cases explicitly defined in the tests was to explain the behaviour around truncating / padding. Using getExpectedString instead and adding the 32byte value to the validValues array, I found that the special cases were duplicates, so I removed them and added a comment to the getExpectedString function to explain. |
|
@jeffsmale90 I added one typo fix to that new comment, but I've approved. |
Co-authored-by: Micaiah Reid <micaiahreid@gmail.com>
…m-address and json-rpc-data (trufflesuite#2716) fixes trufflesuite#1594
fixes #1594