-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Allow re-use of chain reader tests outside go testing to allow applications to test against actual chains and optomize the use of the contracts. #13280
Conversation
I see you updated files related to
|
e5bdae7
to
b52a16f
Compare
b52a16f
to
48d9e5b
Compare
48d9e5b
to
d3ecbda
Compare
db := it.Helper.NewSqlxDB(t) | ||
lpOpts := logpoller.Opts{ | ||
PollPeriod: time.Millisecond, | ||
FinalityDepth: 4, |
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 left this the same as it was before I did refactoring figuring that I could make tests run in a reasonable time. Would it make more sense for me to make this configurable so that things like finality breaches could be caught by the test? Does anyone know the impact of waiting for finality? For example, how long would it take to deploy a contract then send four transactions and wait for their events on Sepolia?
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.
If we are only testing the ChainReader interface, I don't think finality matters so much as returning valid structured data. While the ChainReader interface tests are sort of integration tests with the underlying log poller, adjusting finality here seems to just duplicate logpoller tests. Maybe I'm missing something?
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.
Agreed, that's why I left it, I just wanted to present the the option and where it could benefit us. I'm not sure there would be much gain anyways, because finality breaches aren't constant anyway. So the odds you get one during a test seem close to zero.
Quality Gate passedIssues Measures |
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
db := it.Helper.NewSqlxDB(t) | ||
lpOpts := logpoller.Opts{ | ||
PollPeriod: time.Millisecond, | ||
FinalityDepth: 4, |
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.
If we are only testing the ChainReader interface, I don't think finality matters so much as returning valid structured data. While the ChainReader interface tests are sort of integration tests with the underlying log poller, adjusting finality here seems to just duplicate logpoller tests. Maybe I'm missing something?
8c8e299
to
36cab61
Compare
core/services/relay/evm/evmtesting/chain_reader_interface_tester.go
Outdated
Show resolved
Hide resolved
core/services/relay/evm/evmtesting/chain_reader_interface_tester.go
Outdated
Show resolved
Hide resolved
36cab61
to
2e6d8fd
Compare
2e6d8fd
to
e23f756
Compare
…ations to test against actual chains and optomize the use of the contracts.
e23f756
to
3d721fc
Compare
No description provided.