importantly this doesn't conflate exceptions and values like the Midje =not=> does, which has traditionally lead to many uncaught bugs in our test suites:
(facts "=not=> vs mismatch"
(fact "wHHYYY does this pass?"
(throw (ex-info "boom" {})) =not=> 1)
(fact "we sleep well at night knowing this doesn't pass"
(throw (ex-info "boom" {})) => (match (m/mismatch 1))))
useful for asserting that something is not in the result: https://github.com/nubank/matcher-combinators/issues/99 for example:
open questions:
mismatch
lead to more readable tests in general?semantics
in your head?for both of these questions I decided to discourage negation matching in the README and the docstring
example failure messages
other
importantly this doesn't conflate exceptions and values like the Midje
=not=>
does, which has traditionally lead to many uncaught bugs in our test suites: