-
Notifications
You must be signed in to change notification settings - Fork 228
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
p2p: break out tests into separate crate #898
Conversation
8d4aa7b
to
0cb4e80
Compare
Codecov Report
@@ Coverage Diff @@
## master #898 +/- ##
========================================
+ Coverage 69.7% 70.4% +0.6%
========================================
Files 200 203 +3
Lines 16319 16189 -130
========================================
+ Hits 11383 11400 +17
+ Misses 4936 4789 -147
Continue to review full report at Codecov.
|
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.
So I understand that having a separate test crate for cross-crate integration testing makes sense, but I'm not totally clear on the reasoning behind moving (what appear to be, at least) unit tests into a separate crate.
@@ -7,13 +7,13 @@ use thiserror::Error; | |||
pub enum Error { | |||
/// Cryptographic operation failed | |||
#[error("cryptographic error")] | |||
CryptoError, | |||
Crypto, |
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.
These would be considered API-breaking changes, right? If so, please add an entry to .changelog/unreleased/breaking-changes
.
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.
Add an entry, could you double check that this correctly formatted?
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.
Seems good - we can always tweak formatting during the next release.
@@ -0,0 +1 @@ | |||
mod unit; |
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.
Just so I understand, why are these unit tests broken out into a separate crate? If they're unit tests, shouldn't they stay in the tendermint-p2p
crate, alongside the secret connection code?
@thanethomson A main source of reconsidering the testing story in Rust comes from this article: https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html Esp. the later parts where where it goes into detail how code including unit test code is treated during compilation. |
Interesting! So this is effectively an optimization? It does seem like a good idea to test all publicly exposed APIs from within a single crate. I suppose then that the only tests that would be located outside of the |
You can look at it that way for sure, for me that is a means to an end, in this case developer experience. Where we optimise for tight feedback loops by being adamant about how quickly things fail/pass.
Exactly, I'd be surprised that there are more of a handful of cases for private functionality to be tested. |
In order to explore a path forward where testing utilities as well as the assertions for a single and across crates, this change moves the secret connection tests into the newly introduced test crate. Signed-off-by: Alexander Simmerl <a.simmerl@gmail.com>
0cb4e80
to
aa3f2db
Compare
In order to explore a path forward where testing utilities as well as
the assertions for a single and across crates, this change moves the
secret connection tests into the newly introduced test crate.