Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Change matcher protocol and definition API to not reference `should` and `should_not` #270
We've been moving in the direction of
The specific APIs:
I don't have a proposal for new names for these yet...this is mostly a place holder issue to facilitate discussion :).
So I'm thinking s/should/expectation/ on most of these and s/should not/negative expectation. That is:
I like @samphippen's suggestions, personally.
Interesting idea, but IMO, "mismatch" gives the wrong sense: to me, a mismatch, suggests a failure of an attempted positive expectation. It doesn't suggest a negative expectation to me.
On the built-in matchers, we've discussed aliasing
I don't like any of the options presented here, but I don't have a better suggestion. The words positive or negative or negated apply to the expectation, not the message. I think these names tell the right story:
... but obviously they are painfully long.
FYI - the original names were
I can almost get behind @myronmarston's suggestion (
Wish I had a better answer. Good luck!
Of the proposals thus far, I prefer @myronmarston 's
The similarly-prefixed methods go together, which makes it clearer to me. Negated is descriptive, but will not be as self-evident.
Funny how it's hard to get consensus on this!
A few points of clarification (although these things may already be obvious):
At this point, I think I like @JonRowe's suggestion the best:
match match_when_negated failure_message failure_message_when_negated
Barring a better suggestion between now and however long it takes me to put up a PR for this, that's what I'll go with. Any objections?