Allow hspec-hedgehog to produce more compact output

[sol]

This requires:

• Allow to disable the recheckAt-message #519
• Support empty property names #520
• Allow to omit source location from report #523
• Allow to omit icons at the start of important output lines #524

Before:

After:

[sol]

@moodmosaic that's all that I have on my wish list. After that, I'm pretty happy with the output.

[moodmosaic]

@moodmosaic that's all that I have on my wish list. After that, I'm pretty happy with the output.

Planning for a release after #525. 🎉

[sol]

#519 (comment)

@ChickenProp we could still include the "shrink path", I guess.

From what I understand, this only affects performance. Do you regularly run into situations where this makes a practical difference?

[ChickenProp]

I regularly run into situations where it makes a big practical difference to performance :p Like, it can be several minutes versus a few seconds.

But also, it can really help debugging. I often use print or trace statements to help, and if I don't use the shrink path, the last lines of output are often from tests that passed. Or I'll do stuff with a database, and then the database state at the end has been changed by tests that passed. With the shrink path, I know the last attempt failed, which is super helpful. (If I want that with quickcheck, I kind of have to binary search to find the lowest --qc-max-shrinks value that gives the full number of successful shrinks.)

(I did notice that the shrink path is also visible at the top of the failure message, so there's that too. But it's a lot easier for me if it's at the bottom.)

[sol]

I did notice that the shrink path is also visible at the top of the failure message, so there's that too.

It's gone now, see screens, but we could bring it back.

But it's a lot easier for me if it's at the bottom.

Given that the output will be much more compact now (mostly due to #505), does this still matter?

[ChickenProp]

It's gone now, see screens, but we could bring it back.

Oh, right. My inclination would be to leave it, or at any rate not to disable it along with the recheckAt message. But for myself, I'm still likely to re-enable the recheckAt message, so as long as I can do that in my environment and forget about it, it's not gonna make a big difference to me.

Given that the output will be much more compact now (mostly due to #505), does this still matter?

I think so, yeah. Sometimes there'll be annotations which presumably make the output big again, but even apart from that, I think it's easier to visually scan for if I know it's near the bottom.

[moodmosaic]

@sol, @ChickenProp, happy to plan for a release and/or also wait until this is resolved/closed. Let me know if there's anything I can do to help.

[sol]

@ChickenProp we will keep the shrink path for now #531. The long-term plan is to add more options to Hspec to allow you to get the full reproduce message and possibly also to allow skipping to specific hedgehog tests.

[sol]

@moodmosaic after #531 I think we are good to go.

[ChickenProp]

So I'd still be happier if there's some way (e.g. environment variable) to get the full reproduce message when using hspec-hedgehog. There's a question in my mind of whether that counts as hedgehog's responsibility or hspec-hedgehog's?

That is, I could imagine hedgehog having environment variables to set the config, and I could imagine them either being defaults or overriding what the programmer passes in. (I lean towards the latter, and I think that could be implemented with a minor version bump.) But it's not clear hedgehog needs that. If the normal usage is that renderResultWith is written directly in the source code that the programmer has access to, they can just change the config in code. Maybe that's just fine. hspec-hedgehog has renderResultWith written somewhere the programmer can't easily change it, but that doesn't need to be hedgehog's problem. In which case maybe this discussion belongs at hspec/hspec-hedgehog#35?

At any rate, I think this is a clear improvement to hedgehog as-is, and I think a release after #531 makes sense.

[sol]

but that doesn't need to be hedgehog's problem. In which case maybe this discussion belongs at hspec/hspec-hedgehog#35?

That was my line of thought. hedgehog now offers enough flexibility to allow hspec-hedgehog to take advantage of it in various ways.

At any rate, I think this is a clear improvement to hedgehog as-is, and I think a release after #531 makes sense.

Great 👍 @moodmosaic I guess that means "yes, we can move forward with a release" after #531.

[moodmosaic]

@sol, @ChickenProp, thank you for the feedback. 💯 #531 is just merged. 🎉