Add initial set of conformance tests for Stream #43834
Conversation
stephentoub
added
area-System.IO
breaking-change
ghost
added
the
needs-breaking-change-doc-created
stephentoub
force-pushed
the
streamconformance
branch
3 times, most recently
from
56ecc67 to
7f45cf0
Compare
stephentoub
force-pushed
the
streamconformance
branch
from
7f45cf0 to
a3c5822
Compare
src/libraries/Common/tests/Tests/System/IO/StreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/tests/Tests/System/IO/StreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/tests/Tests/System/IO/StreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/tests/Tests/System/IO/StreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
...libraries/System.Net.Quic/tests/FunctionalTests/QuicStreamConnectedStreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamConformanceTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/tests/FunctionalTests/NetworkStreamTest.cs
Outdated
Show resolved
Hide resolved
|
I think we should also consider using the WrappedConnectedStreamTests for HttpClient request/response streams. This is a little weird because we don't actually have a Stream implementation on the server side -- but we could hack this together on top of the various loopback server stuff fairly easily. Thoughts? |
There are more streams in dotnet/runtime than I've included here. My thinking was we'd get this framework in, and then folks can add additional streams to test and additional tests over time. I got many of the heavy hitters here. |
stephentoub
force-pushed
the
streamconformance
branch
2 times, most recently
from
7108d31 to
d139d8a
Compare
|
@scalablecory Can we go ahead and fix the Dispose behavior in QuicStream? Any reason to hold off on this? There are other issues in #756 that may need additional consideration, but it would be nice to fix the Dispose issues and make these conformance tests work for QuicStream. |
No reason to hold off. It has been a thorn in my side for HTTP/3 so I would very much like to fix it :). |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
@geoffkizer, fyi, my machine isn't set up to run these, and they don't appear to run in CI yet (correct me if I'm wrong). So you may need to tweak them once they're merged.
This can be hit by calling code and thus shouldn't be an assert. As an assert it prevents testing.
These primarily focus on "connected streams", ones that can be arranged to communicate with each other in a producer/consumer pattern or as a bidirectional communication mechanism, e.g. NetworkStream, PipeStream, SslStream wrapped around a NetworkStream, FileStream created around pipes, etc. Later we can add more tests focused on standalone streams, e.g. FileStream created for an on-disk file, MemoryStream, etc.
These are currently helpers used by many other tests. At some point they could become public API as well.
Technically a breaking change, but the current divergence from the base Stream class is a bug, and bringing them into sync means argument exceptions that emerge from the derived type make sense when used via the base type, as well as then being able to use shared validation logic across all streams (subsequent to these changes).
1. Flushing a stream that wraps another stream for writing should always flush that underlying stream, even if no additional data was written as part of the flush. 2. Argument validation should validate buffers are not null rather than null ref'ing on a null buffer. 3. Checks for the CryptoStream mode should come after argument validation.
Technically a breaking change, but the current divergence from the base Stream class is a bug, and bringing them into sync means argument exceptions that emerge from the derived type make sense when used via the base type, as well as then being able to use shared validation logic across all streams (subsequent to these changes).
Technically a breaking change, but the current divergence from the base Stream class is a bug, and bringing them into sync means argument exceptions that emerge from the derived type make sense when used via the base type, as well as then being able to use shared validation logic across all streams (subsequent to these changes).
Specifically when used in a connected fashion, wrapped around an anonymous or named pipe.
Specifically when used in a connected fashion, wrapped around some other connected stream.
Consumers may expect Stream.Flush to be a nop if the stream is readable only, but PipeStream.Flush is throwing in that case. Stop doing that.
1. When passed a null buffer, it's throwing an exception with the argument name "array", even though the parameter's name is "buffer".
2. Even if there's no data written as part of the Flush{Async} call on a writeable stream, it should be calling flush on the wrapped stream.
1. DeflateStream.Flush{Async} when writing needs to always flush the underlying stream, even if there's no data written as part of the flush call itself.
2. Several byte[] array arguments should be byte[] buffer. Technically a breaking change, but the current divergence from the base Stream class is a bug, and bringing them into sync means argument exceptions that emerge from the derived type make sense when used via the base type, as well as then being able to use shared validation logic across all streams (subsequent to these changes).
3. DeflateStream.EndRead/Write needs to do additional state validation.
4. Not a bug, but simplify ReadAsync to match the sync Read implementation flow.
stephentoub
force-pushed
the
streamconformance
branch
from
d139d8a to
ac6aff5
Compare
ghost
locked as resolved and limited conversation to collaborators
|
@stephentoub @PriyaPurkayastha Can you create a breaking change docs issue for this here? I believe this went out in Preview 1. |
|
@gewarren, I've opened dotnet/docs#23102. Thanks. |
|
@ericstj, you assigned this to me. What's the action item? |
|
Mail is coming shortly. I'm going through all PRs with needs-breaking-change-doc and asking folks to file those issues and remove the label. |
|
Ok. As noted above in the comments, dotnet/docs#23102 was already opened and addressed. |
stephentoub
removed
the
needs-breaking-change-doc-created
|
Thanks for removing the label, that will remove this from my queries. |
6 participants
This also includes fixes to a variety of streams where they're out of conformance, in particular around argument names.
The tests being added are primarily focused on "connected streams", ones where two streams are used to represent two ends of a communication channel. We can subsequently flesh this out for other kinds of streams. Also, while I consolidated a bunch of tests that were spread across different stream-derived type tests, there's still more that can be consolidated over time into these centralized tests.
cc: @geoffkizer, @ericstj, @terrajobst