Add unit tests for SSL/TLS#413
Conversation
- Add tests to connect to HTTPS hosts. - Update companion app to allow testing secure server and certs.
- Add tests to connect to HTTPS hosts. - Update companion app to allow testing secure server and certs.
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: nanoframework/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughAdds TLS echo and connection commands to the Network Test Companion, introduces shared TLS test infrastructure, and adds WiFi and non-WiFi SslStream test projects covering TLS client validation, server handshakes, echo exchanges, connection reuse, and peer-closure behavior. ChangesTLS stream testing
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant SslServerTests
participant CompanionClient
participant CommandServer
participant TlsEchoServer
SslServerTests->>CompanionClient: Request TLS echo or TLS connection
CompanionClient->>CommandServer: Send JSON control command
CommandServer->>TlsEchoServer: Start server or establish TLS client
TlsEchoServer-->>SslServerTests: Complete TLS handshake and echo data
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Tests/NetworkTestCompanion/CommandServer.cs`:
- Around line 302-328: Update the TLS command handlers, including TlsConnectEcho
and the background operation shown, so they expose a bounded operation
status/result that callers can query after the server flow completes instead of
returning Ok() immediately. Track handshake and read failures in that result,
compare the bytes received by TlsConnectEcho with the expected echoed payload,
and report mismatches. Apply cancellation and explicit timeouts to handshakes,
delays, and reads, ensuring cleanup completes without orphaned tasks or
connections.
In `@Tests/NetworkTestCompanion/Program.cs`:
- Line 10: Update the WellKnownTcpPorts configuration to include TCP port 7015,
preserving the existing ports and enabling --setup-firewall runs for the
companion TLS server used by DeviceAsClient_WriteAfterPeerClose_ShouldThrow.
In `@Tests/SocketTests/CompanionClient.cs`:
- Around line 106-126: Update the control-channel read around the receive loop
in CompanionClient so it performs one bounded Socket.Receive call and returns
the received response immediately, rather than retrying after partial data.
Preserve the larger receive buffer and existing UTF-8 decoding, while removing
the maxAttempts loop, newline polling, and associated sleep.
In `@Tests/SslStreamTests_WiFi/SslClientTests.cs`:
- Around line 205-210: Prevent unexpected InvalidOperationException instances
from being treated as successful outcomes in the SslClientTests exception paths.
In Tests/SslStreamTests_WiFi/SslClientTests.cs at lines 205-210, 255-261, and
304-310, remove each catch block or rethrow the caught exception after any
required logging, while preserving the expected CryptographicException handling
so TLS setup failures are reported by the test framework.
- Around line 399-419: Replace the expired InvalidCACert fixture with a
currently valid, unexpired certificate issued by a different CA, preserving the
intended mismatch with howsmyssl.com so validation specifically reports
MBEDTLS_X509_BADCERT_NOT_TRUSTED. Update the adjacent comments if the
replacement certificate’s identity changes, and keep the existing test assertion
behavior unchanged.
- Line 40: Dispose the CancellationTokenSource created in SslClientTests by
wrapping its usage in an appropriate disposal scope or otherwise ensuring
disposal after the test completes, while preserving the existing cancellation
behavior and 60-second timeout.
In `@Tests/SslStreamTests_WiFi/SslServerTests.cs`:
- Around line 43-48: Remove the unconditional Assert.SkipTest call from Setup so
the SSL server tests execute in committed builds. Replace it with the
repository’s existing test-configuration or hardware-environment gate, allowing
tests to skip automatically only when the required real hardware or companion is
unavailable.
- Around line 159-168: Update both TLS read assertions in
Tests/SslStreamTests_WiFi/SslServerTests.cs at lines 159-168 and 215-223 to
accumulate reads until testData.Length and sent.Length bytes are received,
respectively, or stop on EOF. Perform byte comparisons only after the expected
payload is complete, preserving the existing exact-length and content
validations.
- Around line 390-406: Update the exception handling in the
Assert.ThrowsException write loop to normalize only the documented
SocketException into the expected IOException. Allow existing IOException
instances to propagate unchanged, and do not catch or convert other exception
types so unrelated failures still fail the test.
In `@Tests/SslStreamTests_WiFi/SslStreamTests_WiFi.nfproj`:
- Around line 38-63: Update all NuGet dependencies to the latest versions by
running nuget update for both test projects and committing the generated
changes. Update package references in
Tests/SslStreamTests_WiFi/SslStreamTests_WiFi.nfproj (38-63),
Tests/SslStreamTests/SslStreamTests.nfproj (41-60), and package versions in
Tests/SslStreamTests/packages.config (1-8); also update the corresponding WiFi
packages.config and both packages.lock.json files.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: nanoframework/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1e82e5b1-2fb2-4cf1-a2f5-971e8e055d4d
📒 Files selected for processing (17)
.gitignore.runsettingsTests/NetworkTestCompanion/CommandServer.csTests/NetworkTestCompanion/Program.csTests/NetworkTestCompanion/TestCertificates.csTests/NetworkTestCompanion/TlsEchoServer.csTests/SocketTests/CompanionClient.csTests/SslStreamTests/Properties/AssemblyInfo.csTests/SslStreamTests/SslStreamTests.nfprojTests/SslStreamTests/packages.configTests/SslStreamTests_WiFi/Properties/AssemblyInfo.csTests/SslStreamTests_WiFi/SslClientTests.csTests/SslStreamTests_WiFi/SslServerTests.csTests/SslStreamTests_WiFi/SslStreamTests_WiFi.nfprojTests/SslStreamTests_WiFi/TestConfiguration.csTests/SslStreamTests_WiFi/packages.confignanoFramework.System.Net.sln
|
Expected failure on nugets check in WiFi test project: we're ferencing System.Net directly. |
Description
Motivation and Context
How Has This Been Tested?
Screenshots
Types of changes
Checklist: