Fluentassertions: [Request] Custom validations on 'Stream' types

[julealgon]

Description

I've come across a few scenarios where I need to validate specific properties and property combinations on Stream instances. I noticed the library does not expose any custom validations for such types so I had to workaround it.

I'd like to see simple validations such as:

• .BeWritable (stream.CanWrite)
• .BeReadable (stream.CanRead)
• .BeReadOnly (stream.CanRead && !stream.CanWrite)
• .BeWriteOnly (stream.CanWrite && !stream.CanRead)
• .BeSeekable (stream.CanSeek)

As well as potentially more advanced validations such as:

• .HaveContentsEquivalentTo(byte[]) (matches a given byte[] for readable streams)

Expected behavior:

stream.Should().BeReadOnly();

Actual behavior:

using (new AssertionScope())
{
    stream.CanRead.Should().BeTrue();
    stream.CanWrite.Should().BeFalse();
}

Versions

• Which version of Fluent Assertions are you using?
  5.10.3

• Which .NET runtime and version are you targeting? E.g. .NET framework 4.6.1 or .NET Core 2.1.
  Net Core 3.1 / Net 5

Additional Information

Related to #961

[jnyrup]

Sounds like a good start to me :+1:

For completeness it should also have:

• NotBeSeekable
• NotBeReadable
• NotBeWritable
  
  
  
  • Writability and readability are independent properties.
    
    E.g. an initially writeonly stream being in a state where it has been closed for further writing. It is now not readonly but at the same time not writeonly.
  
  

It should maybe have

• HaveLength/NotHaveLength
  
  
  
  • This _may_ throw NotSupportedException for non-seekable streams.
  
  

I'm not sure about the HaveContentsEquivalentTo as would require us to make assumptions on _how_ to consume the particular stream.
That might make a strong coupling on implementation details.

The StreamAssertions should be generic in TStream, such that it:

• retains the compile-time type of the stream and
• allows for type specific derivations of StreamAssertions

[julealgon]

I'm not sure about the HaveContentsEquivalentTo as would require us to make assumptions on how to consume the particular stream.

Can you elaborate what assumptions you are foreseeing?

As long as the comparison is with a byte[] I don't think there would be much to it, since you can read the bytes from a stream regardless of stream type, right?

[jnyrup]

My initial thoughts are:

• An infinite Stream that can never be fully consumed.
  
  
  
  • This could be handled by reading at most expected.Length bytes.
  
  
• Failing to read from a write-only Stream.
• A Stream where a using CopyTo would give sync-over-async execution.