-
Notifications
You must be signed in to change notification settings - Fork 12
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
test: add integration tests for Upgradable
#79
Conversation
All plugins are now tested in integration tests.
/// TODO stage code that corresponds to a valid contract. Call a method of that contract to verify | ||
/// the staged code was deployed. |
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.
Carrying over this TODO. I suggest to tackle it in a separate PR.
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, nice work
// Estimating a number of blocks to skip based on `duration` and calling `fast_forward` only | ||
// once seems more efficient. However, that leads to jittery tests as `fast_forward` may _not_ | ||
// forward the block timestamp significantly. |
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 feel like there's a middle ground here where we can fast-forward in larger steps until the duration to wait is smaller. For example, if we are skipping 10s into the future then it seems safe that we could skip 5 blocks and then check how much farther we need to go.
But then again, this is only used in tests so you're probably right that it is not worth the additional complexity for a minor speed-up. Let's leave it as-is unless it becomes a problem.
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.
It’s tricky because we need to move forward in time but worker.fast_forward
moves forward in blocks. Since forwarding by multiple blocks still may not forward the timestamp, I guess finding that middle ground is difficult. That’s why I went for this very naive approach.
* Add integration tests * Add Deserialize to derived traits * Remove unit tests * Remove dead util code for unit tests All plugins are now tested in integration tests. * Remove outdated paragraph from README
Adds integration tests and removes the corresponding unit tests. The background and motivation are described in #51, which does the same for
Pausable
.Expands test coverage compared to previous unit tests.