Runtime testing #243
Runtime testing #243
Conversation
g-r-a-n-t
force-pushed
the
runtime-testing
branch
3 times, most recently
from
5866d49
to
b6c45fd
Compare
Codecov Report
@@ Coverage Diff @@
## master #243 +/- ##
=======================================
Coverage 93.91% 93.91%
=======================================
Files 54 54
Lines 3744 3744
=======================================
Hits 3516 3516
Misses 228 228
Continue to review full report at Codecov.
|
compiler/tests/evm_runtime.rs
Outdated
| (sstore(100, a)) | ||
|
|
||
| // this fails for some reason.. possible bug? | ||
| // [assert_eq!(b, (sloadn(130, 2)))] |
There was a problem hiding this comment.
it looks like this might be a bug @cburgdorf. I could be missing something tho
There was a problem hiding this comment.
This is interesting. You can prove [assert_eq!(0x42, (sloadn(100, 1)))] but that's as far as I got. I tried changing the second byte to anything but 00 and then use sloadn(101, 1) but that already fails. So, maybe a base assumption about how storage works is wrong? 😅
There was a problem hiding this comment.
I'm going to merge this and continue digging into the storage stuff. Pretty cool that we already found an issue with this testing.
|
still a few todo items to check off, but this should be good for a review |
compiler/tests/evm_runtime.rs
Outdated
| (sstore(100, a)) | ||
|
|
||
| // this fails for some reason.. possible bug? | ||
| // [assert_eq!(b, (sloadn(130, 2)))] |
There was a problem hiding this comment.
This is interesting. You can prove [assert_eq!(0x42, (sloadn(100, 1)))] but that's as far as I got. I tried changing the second byte to anything but 00 and then use sloadn(101, 1) but that already fails. So, maybe a base assumption about how storage works is wrong? 😅
g-r-a-n-t
force-pushed
the
runtime-testing
branch
from
b6c45fd
to
da1098c
Compare
What was wrong?
closes #214
How was it fixed?
The solution I used was a bit different than the one proposed in the linked issue. Instead of testing functions in the runtime object of a given contract, the functions are brought in directly from the runtime builder and tested. This seemed like a much more straight forward way of doing things.
test_runtime_functionsthat takes a vector of functions to be tested and a vector of statements to test those functionsassert_eqmacro that builds an if statement that enters and reverts if the assertion is falseTo-Do
Get to the bottom of the apparent
sloadnbugAdd entry to the release notes (may forgo for trivial changes)
Clean up commit history