Add allowFail

[jdnavarro]

This is like expectFail but marks passing tests as successes. This is a workaround for expecting at least one test to fail under a TestTree with multiple leaves.

Ideally, for my particular use case, if all tests succeed, it should be reported as an unexpected failure, but right now I don't have time to figure out how to do so. I guess I'd have to write another version of wrapTest with some TestTree folding.

[nomeata]

This is quite a sledgehammer. Why do you think that the individual tests cannot be marked as expect fail? Is it because some other library might return a complete TestTree?

In that case, maybe you need a expectFailFor pattern function, where pattern is some way of identifying one or more tests.

[jdnavarro]

I acknowledge this is an unusual case.

The need arises from a positive control in a testing library that automatically validates lens laws. Concretely, this is an improper Prism' which should fail. I'm making sure that the testing library catches this case. A priori, I don't need to worry about which concrete law is being violated, I just need to check that there is at least one law that's being violated and should report which case is the offending one.

I don't think this kind of tests will be ever used in consumer code. I could include allowFailin my testing package, but I'm expecting to reuse this function in other law testing packages. Perhaps you could wait for expectAnyFail in #2 which should be less overkill and would make allowFail unnecessary. Do you have any other suggestions?

[nomeata]

Concretely, this is an improper Prism' which should fail.

This is not actually how I understand expectFail. You seem to want to use it to negate a test case result, whereas the intended use case is when the test case is all right, but the implementation is not (yet).

In other words: expectFail is for expected, but undesirable failures, while it looks you need something for expected and desired failures.

But of course nothing wrong with using expectFail in the manner that suits you :-)

Perhaps you could wait for expectAnyFail in #2 which should be less overkill.

I’d prefer to do that, yes.

[jdnavarro]

Alright, I'll take care of #2 and send a new PR.

But of course nothing wrong with using expectFail in the manner that suits you :-)

I confess I'm piggybacking here 🐷, but I'm glad you are OK with it :-)