Consider printing failing test case before shrinking

[furuholm]

I would prefer the failing test case to be printed before shrinking is started. Alternatively:

• Allow the print of the original test case to be controlled by a configuration parameter.
• Print that a failing test case was found and that shrinking has started. This is probably most relevant for tests that are not slow to shrink, but in my experience this is not unusual for stateful tests at least.

[emil-e]

I general, I think the default should be to not print anything except on failure since most of the time you run a test suite, the expected outcome is success and then you don't really want any output.

The latter option is already pretty much implemented in the configuration parameter verbose_shrinking which if set to 1 will print stuff during shrinking, indicating to the developer that in fact a failure did occur and now we are shrinking.

As I understand it, you want to be able to see the original test case and I guess that's fair enough but the right solution depends on the purpose of this.

• If the reason is that you want to be able to see the original test case if shrinking takes too long, I would guess the original test case will be pretty useless to you if shrinking is slow because that usually means that the original test case is very complex. Unshrunk test cases are usually pretty incomprehensible in my experience.
• If the reason is for development purposes (see the original test case), I'd probably advice that you run the test case again with the reproduce parameter set (see the documentation on reproducing test cases) in combination with noshrink=1 which will be very fast in most cases.

Can you elaborate on the use case?

[emil-e]

@furuholm comment?

[furuholm]

First of all, of course nothing should be printed when the test succeeds.

I don't have a single use case in mind, it's more a combination:

• When tests are non-deterministic you can't rely on reproduce.
• Seeing the complete test case is good for understanding of what RapidCheck does.
• When you run the tests from an IDE it is not zero overhead to add the parameters necessary to reproduce the test case.

I think it would make sense to add this to verbose_shrinking but it could be a separate parameter as well.

If you don't think it makes sense I say close this item.