Drop RespectingRuntimeTypes and RespectingDeclaredTypes

[dennisdoomen]

I propose to drop those two methods for a couple of reasons:

1. They confuse a lot of people
2. Only affect the expectation and not the subject
3. The only affect the top-level members of an object. As soon as BeEquivalentTo goes one level deeper, it will fall-back to the run-time types.

If somebody really wants to include or exclude certain members, they can either use an anonymous type as the expectation or use one of the other APIs to include or exclude certain members.

Also may affect #1860

[jnyrup]

I really like that we revise if the default of only looking at the declared types is still the right choice 👍

I tried removing RespectingRuntimeTypes and RespectingDeclaredTypes and surprisingly only 11 tests failed.

• AssertionRuleSpecs
  • When_the_compile_time_type_does_not_match_the_equality_comparer_type_it_should_use_the_default_mechanics
• CollectionSpecs
  • When_an_object_implements_multiple_IEnumerable_interfaces_but_the_declared_type_is_assignable_to_only_one_it_should_respect_the_declared_type
  • When_the_expectation_is_an_array_of_interface_type_it_should_respect_declared_types
• NestedPropertiesSpecs
  • When_not_all_the_properties_of_the_nested_objects_are_equal_it_should_throw
• SelectionRulesSpecs
  • Excluding_a_covariant_property_through_the_base_class_excludes_the_base_class_property
  • Includes_hidden_field_of_the_base_when_using_a_reference_to_the_base
  • Includes_hidden_property_of_the_base_when_using_a_reference_to_the_base
  • When_respecting_declared_types_explicit_interface_member_on_interfaced_subject_should_be_used
  • When_respecting_declared_types_explicit_interface_member_on_interfaced_expectation_should_be_used
  • When_a_reference_to_an_interface_is_provided_it_should_only_include_those_properties
  • When_a_reference_to_an_explicit_interface_impl_is_provided_it_should_only_include_those_properties

If somebody really wants to include or exclude certain members, they can either use an anonymous type as the expectation or use one of the other APIs to include or exclude certain members.

We should remind ourselves that the expectation might not be a static value, but could also be a computed one.

For When_an_object_implements_multiple_IEnumerable_interfaces_but_the_declared_type_is_assignable_to_only_one_it_should_resp
I don't know how to disambiguate which IEnumerable<> to use.

If we discover properties based on the runtime type, which of the two Name properties should we favor?

class Person : IPerson
{
    public string Name { get; set; }
    
    string IPerson.Name { get; set; }
}

[dennisdoomen]

If we discover properties based on the runtime type, which of the two Name properties should we favor?

In #2152, I've chosen to prefer the normal property over the explicitly implemented one.

We should remind ourselves that the expectation might not be a static value, but could also be a computed one.

We still support various overloads of Excluding that you can use to exclude certain members from the expectation. Or do I misunderstand your point?

I tried removing RespectingRuntimeTypes and RespectingDeclaredTypes and surprisingly only 11 tests failed.

When_respecting_runtime_types_explicit_interface_member_on_interfaced_subject_should_not_be_used would also be affected by removing the options.

[jnyrup]

If we discover properties based on the runtime type, which of the two Name properties should we favor?

In #2152, I've chosen to prefer the normal property over the explicitly implemented one.

👍 I wrote this before my latest review on #2152

We should remind ourselves that the expectation might not be a static value, but could also be a computed one.

We still support various overloads of Excluding that you can use to exclude certain members from the expectation. Or do I misunderstand your point?

I had forgotten we have Exclude for collection members.