If higher-order combinator about testtools HOT 4 OPEN

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.

from testtools.

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?

from testtools.

+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?

from testtools.

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.

from testtools.