-
Notifications
You must be signed in to change notification settings - Fork 146
refactor(s2n-quic): move tests to s2n-quic-tests #2716
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
Conversation
@@ -1,7 +1,7 @@ | |||
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. |
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.
Why not just continue to put the tests in src/tests.rs
? IIRC it should be faster to compile since you don't have to compile and link the intermediate s2n-quic-tests
lib.
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 started out by following the test organization guidance in the Rust book: https://doc.rust-lang.org/book/ch11-03-test-organization.html, but then I came across this blog post which was showing how they organize it in the Cargo repository. So I decided to just pattern it off of Cargo
I did try it just now though and it was actually slower (though that might just be my CPU doing something else at the same time).
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.
Right. That post mentions exactly what I'm talking about:
For an internal library, I avoid integration tests all together. Instead, I use Cargo unit tests for “integration” bits:
src/ lib.rs tests.rs tests/ foo.rs bar.rs
That way, I avoid linking the separate integration tests binary altogether. I also have access to non-pub API of the crate, which is often useful.
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.
ah I remember seeing that, but I was getting hung up on "internal library". I guess in this case the library is s2n-quic-tests
, which is internal
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've moved them back to src
and updated the readme to include the reasoning
Resolved issues:
resolves #2694
Description of changes:
Moves the integration tests from the s2n-quic crate to a new s2n-quic-tests crate and adds a README.md describing the test structure and how to run them.
Call-outs:
The
s2n-quic-tls
feature flag was previously used to gate the resumption tests based on if the s2n-tls provider was enabled (which it is on unix-based systems). This feature is only defined in thes2n-quic
crate (implicitly through the inclusion of an optionals2n-quic-tls
dependency. I had trouble utilizing the same feature flag in the news2n-quic-tests
crate, so instead I'm usingcfg[unix]
to more explicitly gate the compilation of the resumption tests to unix-based systems.Testing:
Verified successful test count before and after migration:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.