-
Notifications
You must be signed in to change notification settings - Fork 136
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
PoolSv2
integration tests
#1066
PoolSv2
integration tests
#1066
Conversation
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
0dde2c8
to
9dc8a6c
Compare
8ace1ac
to
e90b991
Compare
c0dbde4
to
fbb8464
Compare
56c26c0
to
6cfc1c7
Compare
a3f154b
to
0be5cc6
Compare
@pavlenex hmm not really as we start addressing #1121 we might add a few unit tests to pool, which will indeed fall under #106 but that doesn't necessarily mean that the scope of #106 will be fully addressed, since MG tests are not comprehensive ideally we should eventually jump into #106 as a task on its own... but I'd leave that for some time in the future |
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.
Looks good at first glance. I'll provide a detailed review by tomorrow.
.safe_lock(|messages| messages.is_empty()) | ||
.unwrap() | ||
} | ||
|
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.
Can we add a front method as well. Because sometime we might not want to consume the element to refer.
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.
hmm can you elaborate?
under which circumstances do you see it being useful to look at the message without popping it from the FIFO?
} | ||
_ => panic!("Pool did not send a message to template provider"), | ||
}; | ||
assert!(sniffer.expect_upstream_message(MESSAGE_TYPE_SETUP_CONNECTION_SUCCESS)); |
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.
assert!(sniffer.expect_upstream_message(MESSAGE_TYPE_SETUP_CONNECTION_SUCCESS)); | |
// only assert message type | |
assert!(sniffer.expect_upstream_message(MESSAGE_TYPE_SETUP_CONNECTION_SUCCESS)); |
aa34ac1
to
32f62f7
Compare
Oh I just noticed that |
PoolMessages::$one($two::$three($four {$($expected_property,)*.. }, this makes assert_message!(Common, CommonMessages, $msg, $expected_message_variant); or at least 6 arguments in case of asserting with property validation(could be more if you validate more than one property) assert_message!(Common, CommonMessages, $msg, $expected_message_variant, $($expected_property, $expected_property_value),*); note that we could reduce this to 3 and 5 arguments respectively, but that would require introducing breaking change where we either change because of the above I decided to split it in a way that resembles how |
Handle errors in `start` function for better user experience and to be able to catch errors in test environment, for example without introducing error handling, we do not get a proper response if the provided `coinbase_output` in the config is valid.
Sniffer allows to intercept messages sent between two roles. The sniffer sets between the downstream and upstream roles, aggregates messages sent by the downstream and upstream roles in two separate FIFO queues. The messages are then forwarded to the target role without any modification. It is useful for testing purposes, as it allows to assert that the roles have sent specific messages in a specific order and to inspect the messages details.
A utility struct that wraps the original `PoolSv2` and allows to start the pool role in testing env.
An abstraction above the `TemplateProvider` struct to start TP and mine needed blocks in a single function call.
Stopps the TP running instance in case of test failure.
Starts a Template Provider and Pool and checks that both roles send the corrects messages on first connection.
Align `tests-integration` rust version with the other roles inside the `roles` workspace, otherwise weird problems pops in CI.
32f62f7
to
52a2155
Compare
@GitGab19
|
Amazing, thanks for adding docs, this will make writing test easier for everyone 🙏 |
Blocked by #1155 and #1156
for more context: