integration test #53
No reviewers
Labels
No Label
bug
critical
documentation
duplicate
enhancement
Epic
good first issue
help wanted
Integration tests
invalid
question
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/ipld-eth-server#53
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "integration_tests"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ -645,3 +695,3 @@
storageVal, err := pea.B.GetStorageByNumberOrHash(ctx, address, common.HexToHash(key), blockNrOrHash)
if storageVal != nil && err == nil {
return storageVal, nil
var value common.Hash
Did you confirm this behaviour against the standard JSON RPC API endpoint, i.e. expected result when the storage slot doesn't exist.
Add a comment explaining this value?
How are we confirming expected behaviour (same question for all new assertions)?
@ -645,3 +695,3 @@
storageVal, err := pea.B.GetStorageByNumberOrHash(ctx, address, common.HexToHash(key), blockNrOrHash)
if storageVal != nil && err == nil {
return storageVal, nil
var value common.Hash
Yeah I think this is undoing one of the fixes Ramil made here, the unit test is broken in what it is expecting rather than what it is receiving in this case (and probably all the cases where the unit tests were broken by the changes made in this PR, as the unit tests were passing before them). The majority of the problems this PR is fixing are due to me not anticipating (and failing to test) what the correct expected results were for error and nil cases. Ramil's integration tests compare the results to the results from a standard ETH JSON-RPC client so those are the source of truth.
@ -645,3 +695,3 @@
storageVal, err := pea.B.GetStorageByNumberOrHash(ctx, address, common.HexToHash(key), blockNrOrHash)
if storageVal != nil && err == nil {
return storageVal, nil
var value common.Hash
Yes, I confirmed the behavior manually.
We have two tests suite:
Unit test: Which makes calls to the DB and checks expectations.
Integration test: Which compares ETH and IPLD APIs response.
I will check if there is an Integration test for the same or else I will add it.
https://github.com/vulcanize/ipld-eth-server/pull/53#discussion_r645290501
Done
@ -22,3 +22,3 @@
- db
image: vulcanize/statediff-migrations:v0.3.0
image: vulcanize/statediff-migrations:v0.4.0
environment:
Check if this is the latest one?
@ -0,0 +1,15 @@
Spin up services:
Add documentation on how to run the unit and integration tests.
@ -0,0 +1,15 @@
Spin up services:
Done
@ -22,3 +22,3 @@
- db
image: vulcanize/statediff-migrations:v0.3.0
image: vulcanize/statediff-migrations:v0.4.0
environment:
The test fails after upgrading the docker images.
Typo ("intrgration")
Done
Looks great! Left a few nitpicky comments, otherwise this is good to merge.
@ -22,3 +22,3 @@
- db
image: vulcanize/statediff-migrations:v0.3.0
image: vulcanize/statediff-migrations:v0.4.0
environment:
Latest is v0.5.0
Should move this dep into the section below
@ -244,23 +244,91 @@ func newRPCTransactionFromBlockIndex(b *types.Block, index uint64) *RPCTransacti
}
This continue doesn't need the label
@ -430,3 +430,2 @@
// RetrieveStorageAtByAddressAndStorageKeyAndBlockHash returns the cid and rlp bytes for the storage value corresponding to the provided address, storage key, and block hash
func (r *IPLDRetriever) RetrieveStorageAtByAddressAndStorageKeyAndBlockHash(address common.Address, storageLeafKey, hash common.Hash) (string, []byte, error) {
// RetrieveStorageAtByAddressAndStorageSlotAndBlockHash returns the cid and rlp bytes for the storage value corresponding to the provided address, storage slot, and block hash
The name of this function implies the actual storage leaf key is provided to it, it shouldn't need to hash it again. If an actual storage key was provided this hashing would break the function. We should perform the hashing of the slot key into the leaf key at the level above or change the name to
RetrieveStorageAtByAddressAndStorageSlotAndBlockHash
so that the name aligns with the behavior.Done
@ -244,23 +244,91 @@ func newRPCTransactionFromBlockIndex(b *types.Block, index uint64) *RPCTransacti
}
Done
@ -430,3 +430,2 @@
// RetrieveStorageAtByAddressAndStorageKeyAndBlockHash returns the cid and rlp bytes for the storage value corresponding to the provided address, storage key, and block hash
func (r *IPLDRetriever) RetrieveStorageAtByAddressAndStorageKeyAndBlockHash(address common.Address, storageLeafKey, hash common.Hash) (string, []byte, error) {
// RetrieveStorageAtByAddressAndStorageSlotAndBlockHash returns the cid and rlp bytes for the storage value corresponding to the provided address, storage slot, and block hash
Updated it to
RetrieveStorageAtByAddressAndStorageSlotAndBlockHash
since the api gives us storage slot.The tests fail after updating the docker images. Created an issue for this https://github.com/vulcanize/ipld-eth-server/issues/73