EqualTo et al

[BobSammers]

The documentation for AssertionHelper says:

In addition, AssertionHelper allows the derived class to make direct use of many of the syntactic elements that would normally require you to specify the Is, Has or Does class in order to use them.

I've been replacing my AssertionHelper inheritance in test classes with the using static syntax you've produced for this nuget package and it's partially failed because I've used a similar construct to the example given in the docs:

Expect(actual, EqualTo("Hello"));

Are you considering adding to your static class to offer things such as this?

I can, of course, "solve" the problem by simply adding:

using static NUnit.Framework.Is;

... so there is a trade off between maintaining what are essentially going to be copies of the Is static class and its compatriots and having a series of using static ...s in test projects that wish to use the original AssertionHelper facilities.

(I am assuming this is possible - there could be conflicts between the members of Is, Has and Does that may cause conflicts if more than one is using staticed into play: I haven't checked.)

[fluffynuts]

Personally, I've never used that particular part of AssertionHelper, so it hadn't occurred to me. Apologies!

It would be possible to perform the same kind of shimming that Expect on StaticExpect.Expectations does for Is (and all the other bits of syntax). I'm not against the idea at all, and I also wouldn't be against the idea of pull requests for the functionality (: I'll have a look at it -- in the meantime, I'd appreciate feedback about your idea to statically import NUnit.Framework.Is and any other workarounds, simply because that provides more information from a point-of-view that I haven't experienced (yet).

I'll admit that I'm not actively using NUnit.StaticExpect -- I've moved to using my own NExpect, which I believe offers a better syntax -- and which is designed with user-extensibility in mind. This doesn't mean that NUnit.StaticExpect is abandonware -- it just means that reports like yours are even more valuable for maintaining the library.

I'll go have a look at what I can do about your particular request and feed back here (:

[fluffynuts]

Ok, so I've had a look and I've started on it -- I believe that I've found a fairly painless way to provide what you're looking for. I'll update when I'm ready to release. I'll be hitting Is, Has and Does -- I'd appreciate feedback on what that leaves out as well as what is most important for your current requirements.

[fluffynuts]

Alrighty -- 1.0.1 is out with Is, Has and Does exposed on Expectations, with some footnotes: 1) I would have liked to have tested more, but my battery is running out and it's time to call it quits for the day anyway 2) there were two clashes between properties on the types I'm essentially smooshing together -- I can remember "All" and there was another. I just kept the first I had shimmed when I came across this. They look like they produce the same thing, but I'd like to hear feedback if they don't.

[BobSammers]

Wow - thanks very much for getting on to this and getting it out so quickly! I can confirm that within the test projects I have that use some of these, I can now remove the using static NUnit.Framework.Is; directives I had put in when I moved away from AssertionHelper to StaticExpect.

Unfortunately, I can't claim to be an extensive user of them, nor of either of the other two classes. I did have a look for the clashes you mentioned (I found Not in addition to All) and agree with you that they seem to do exactly the same thing in each case.

A diff between Expectations and AssertionHelper shows a much better correlation than there was before. I think some of the stuff that's still missing is stuff that was defined specially for AssertionHelper (and never documented). For example: EndWith is part of the Does class, but EndsWith (a synonym) and DoesNotEndWith (returning Not.EndsWith) are defined (I think) only in AssertionHelper. The value of replicating them (and maintaining them, if that entails anything at all) probably lies in the number of people who are using these (apparently undocumented) features! I don't believe I ever have.

[fluffynuts]

You're welcome.

The whole point of this library is to provide a drop-in replacement for AssertionHelper, so it makes sense to mimic the full functionality -- at least, the documented functionality, until, as you say, someone requests undocumented features (:

Reports like yours help me to achieve this goal, so thanks to you (: I like that this project has been useful to at least one person (: Nuget.org reports 84 downloads, but I know at least 30 of those aren't "real" (I saw +- 20 downloads on each release of each package I make, so I assume it's from bots and other caching sites -- and I can see that the user agent is sometimes ProGet), but I hope that the other people have found value in the project.

Personally, I don't really like the readability of, for example:

Expect(foo, EqualTo(bar));

But then again, I also grew not to like:

Expect(foo, Is.EqualTo(bar));

mostly for the mixed tenses (Expect is future, Is is present) and partially because I prefer the chai/jasmine:

expect(foo).to.equal(bar);

and I also really wanted to be able to extend assertions like I can in jasmine. Which is why NExpect was born. If you're interested, you can read about it here: https://davydm.blogspot.co.za/2017/09/nexpect-level-1.html

Part of the goal of NExpect is not to tell you how to test, but to facilitate tests which read well. In the same vein, I'm not going to say that AssertionHelper / NUnit.StaticExpect is an inferior way to do things. It's just a different way (: