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
Change matcher protocol #373
BTW, one thing you'll notice I'm doing differently here: I'm adding deprecation warnings to 3.0 rather than breaking things in 3.0 and adding deprecations to 2.99. While it would be nice to make the breaking change in 3.0 and not keep some old cruft around, these API changes are very likely to affect some extension gems (such as shoulda). I don't want users blocked from upgrading to 3.0 because of extension gems they use relying on the old APIs -- thus, I thought it best to retain support for the old protocol in 3.x. We'll plan to drop it in 4.0.
One thing that may surprise users is that they can get warning-free on 2.99, upgrade to 3.0, and then still get warnings. We'll need to make it clear that getting warning free on 2.99 means that their test suite should run on 3.0 w/o any failures, but it does not imply it will run w/o any deprecations.
- failure_message_for_should => failure_message - failure_message_for_should_not => failure_message_when_negated Given that we are moving away from `should`, it would be odd to keep them in these APIs.
Ah, that. That's the positive/negative handler, not the matcher adapters (hence my confusion).
Anyhow, take a look at ef10165 (and the contents of