Restore Intellisense for IsEqualTo

[dupdob]

Since change #246 has been implemented, IsEqualTo requires an object instance as the expected value, which results in the unavailability of auto-completion.

Expected Behavior

Restore support for suggestion features.

Context

Comment by @MendelMonteiro A side effect of this change is that all intellisense is broken when calling IsEqualTo() as it now takes a object instead of T. I personally use IsEqualTo() a lot more often than IsDefaultValue().

[dupdob]

I published V 2.6.1 beta 210 with an early fix. https://www.myget.org/feed/dupdobnightly/package/nuget/NFluent/2.6.1-beta-0210

@MendelMonteiro : could you please test it and confirm if it fixes your issue or not?

[MendelMonteiro]

Will have a look on Thursday morning.

[MendelMonteiro]

It's definitely better as intellisense suggests better options and I'd welcome the change being released.

However, it's not as good as before as you can mix incompatible types and you won't know until you run the test.

[dupdob]

This is a good remark. The short answer is: this is deliberate. But as it deserved a more complete explanations, I just added a page to the wiki to provide the rationale for this choice. Please check this page. Your feedback is welcome of course.

[dupdob]

implemented in V 2.7.0

[MendelMonteiro]

This is a good remark. The short answer is: this is deliberate. But as it deserved a more complete explanations, I just added a page to the wiki to provide the rationale for this choice. Please check this page. Your feedback is welcome of course.

A bit late to reply but I have re-read the explanation in the docs and there must be something I'm not grasping about the TDD explanation. In my experience when writing in a TDD style one of the major benefits is that it helps design the class under test as the test is being written. As that design emerges the class under test will be defined somewhere with at least the name of the class and the members being tested. You cannot test a class that is not defined somewhere yet so how could you test an instance of a class that has not been defined?

If we look at the usual structure of a test we will see

public void Test()
{
    var test = new UnderTest();

    var result = test.DoSomething();

    Check.That(result).IsEqualTo(new Result(42));
}

// Somewhere else you will have to define a skeleton of the classes under test otherwise your test will not even compile:
public class UnderTest
{
    public Result DoSomething(){}
}
public record Result(int Magic);

At what point would we not know the type of the the class under test or the type of the expected value?

[dupdob]

It is never too late 😄. In canonical TDD, does not compile = RED: the test code is written before the code that is to be tested!

[MendelMonteiro]

In practical TDD with intellisense it is a PITA to write test that uses code that has not yet been written. Defining the API which you are testing as you write the test is not the same as writing the implementation that you are testing as you write the test.

Would you write the above test from the bottom up?

[dupdob]

The good news is that everyone can use his favorite TDD cycle. But yes, I would; I think I need to do screen cap for this. Actually, when designing an API, writing the test before the API helps we find the signature I prefer.

[MendelMonteiro]

Writing the Act part first yes, but not writing the Assert part before the Act part...