If higher-order combinator

[mithrandi]

In boolean logic: (p → q) ⇒ ¬p ∨ q

Therefore we can define:

def If(p, q):
    return MatchesAny(Not(p), q)

I didn't supply a patch yet because I thought kicking the idea around a bit might draw out some useful tweaks to the API; for example, what about the common case of If(MatchesPredicate(..., "message that will never be seen"), ...)?

[jml]

This sort of makes me think more that matchers should have a heap of methods on them. e.g.

p.implies(q)

p.after(f).on_mismatch(g)

But each such method added has a huge impact on compatibility.

The Not case sort of already has a bug: https://bugs.launchpad.net/testtools/+bug/704219

I don't know the solution to it, but I suspect that requiring the Mismatch to also provide the mismatched object (as mentioned in #211) might be a part of it.

[thomir]

But each such method added has a huge impact on compatibility.

I agree with @jml. I'd be concerned about adding any complexity to the matcher API. I'm also not entirely sure what the use case is for this. What tests are currently awkward to write that this would resolve?

[rbtcollins]

+1 on being able to propogate the message from an annotated matcher to a higher order matcher.

I think calling a matcher that matches with what you wrote 'If' would be very confusing, because

if foo:
  pass

looks for the truthiness of foo, whereas you're looking for whether p->q has been disproven.

I don't think we should have a heap of methods on matchers. What methods should we add? Why? Why those and not others?

[mithrandi]

The analogy is that this:

self.assertThat(blah, If(Not(Is(None)), GreaterThan(42)))

is equivalent to this:

if blah is not None:
    self.assertGreaterThan(blah, 42)

I can see how that might be confusing, though.