Closed dorranh closed 3 years ago
I'm a bit concerned on us looking at the underlying storage to get some information in order to write this test case; I feel like it would be more realistic if we were only using the public interface (entrypoints and views) to achieve this.
It probably is the case where we don't expose enough views to achieve this. I guess:
There might be more than one possble interface to achieve the above.
I guess, since we are just trying to measure the gas costs it might be fine; but still if some of the things we are doing are natural things to do on checker, we should have a nice way of doing those without having to understand the internal storage.
@utdemir, I totally agree - it was a bit unfortunate having to write a traversal to be able to touch all of the slices. I think that @gkaracha created an issue related to this (https://github.com/tezos-checker/checker/issues/150). Perhaps we can centralize ideas for additional views there?
Ah, yes, that's a very good point @utdemir. Ideally that'd be the case for all our scenaria in the e2e tests I guess.
However: If the operations are just lookups in our storage we could offer them as views, but if they are calculations that we otherwise do not use elsewhere within checker it might not be a good idea to make views for those. They could get out of sync (and I expect advanced users will anyway look into the storage).
Either way I agree that #150 is a good place to keep all ideas for views, we should probably add the two you recommended to the list :+1:
Adds calls to the remaining liquidation auction entrypoints which were previously not called in our end to end tests (#189). To allow this to run in a reasonable amount of time, I had to update our e2e patch to modify the
max_bid_interval_in_blocks
andmax_bid_interval_in_seconds
to much smaller values. Otherwise the test would have to wait up to 20 minutes for the auction to complete.