Improve Using<TMember>
#1494
Improve Using<TMember>
#1494
Conversation
|
Missing release notes and docs Do you think this requires a section in the upgrading guide? |
I think so. It took me a couple of times before I understood what this PR was trying to do. |
|
Hmm... wondering if the implicit cast operator creates more confusion than value? |
But it does simplify the use of this syntax. |
|
Yes, it simplifies the usage, when having To give a more concrete example of the potential confusion about when Say I start out with this snippet and want to exclude a property subject.Should().BeEquivalentTo(expected, opt => opt.
.Using<int>(...)Adding subject.Should().BeEquivalentTo(expected, opt => opt.
.Using<int>(...)
.Excluding(e => e.ExcludeMe)To make it work I have to either put subject.Should().BeEquivalentTo(expected, opt => opt.
.Excluding(e => e.ExcludeMe)
.Using<int>(...)or add subject.Should().BeEquivalentTo(expected, opt => opt.
.Using<int>(...)
.WhenTypeIs<int>()
.Excluding(e => e.ExcludeMe) |
|
I see your point. In the current implementation, it's immediately clear what your options are since Intellisense knows what can be chained at any point in time. |
Was that comment towards keeping or leaving out the implicit conversion operator? |
Merely that I got your doubts about the whole thing. But I don't have a strong opinion on this. |
Restrict `WhenTypeIs<TMemberType>` to types assignable from `TMember`. Make `WhenTypeIs<TMemberType>` optional unless when chaining further. Avoid trying to cast null to non-nullable type.
Restrict
WhenTypeIs<TMemberType>to types assignable toTMember.This should catch
NullReferenceExceptionorInvalidCastExceptioninCreateFromEquivalencyValidationContextat compile-time.The snippet below might have worked, but it assumes that the subject and expectation are both non-null.
Instead, you now have to make this assumption more explicit by using
Nullable<int>.ValueMake
WhenTypeIs<TMemberType>optional unless when chaining further.For the most cases
TMemberTypeis exactlyTMemberand in those casesWhereTypeIs<>()is noisy.By adding an implicit cast operator we can avoid that.
The exception being when we need more chaining after
Using<>, see the addedWhen_overriding_with_custom_assertion_it_should_be_chainable.Avoid trying to cast null to non-nullable type.
This handles when subject or expectation is null, but
Using<int>would either:nulltointleading to a NullReferenceException`, ordefault(int)whenExpectationisnull, which would makenulland0equal.As far as I can read from #33 the changes in
When_a_nullable_property_is_overriden_with_a_custom_assertion_it_should_use_itare fine, as the original bug report was aboutusing<long?>didn't match a non-nulllong?This fixes #799