In FluentAssertions, why should I use a method instead of a property?

In FluentAssertions, you can create various applications in various formats.

x.Should().BeEquivalentTo(y); x.ShouldBeEquivalentTo(y); 

are valid statements.

Why Should method and not a property? I have not seen examples in which Should accept a parameter, so it seems to me that this could be easy.

You can also claim that

 x.Should().NotBeNull().And.BeEquivalentTo(y); 

Here And is a property instead of a method. Should And and Should not be the same type of element (methods / properties)?

TL DR Was there a good reason for choosing a design to make a Should method in FluentAssertions instead of a property?

+5
source share
2 answers

Should() is an extension method added to the x class. You can only add extension methods - C # does not have extension properties.

And - property for any class NotBeNull() . There we control the class and can add real properties to it.

+11
source

Should() is a method due to C # language limitations. This is an extension method; a method defined in the FluentAssertions library that can be called of any type (hence x.Should() ) - even if the source code for the class does not implement this method.

You cannot implement extension properties, therefore Should should be a method.

This method returns an object defined in FluentAssertions , like NotBeNull() , and therefore these objects can include properties in which it is relevant / useful / significant for this.

In short: the real reason is that this is the only option available.

+3
source

Source: https://habr.com/ru/post/1200605/


All Articles