[skohan]

I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.

If you use `assert` in tests, I don't understand why you wouldn't also prefer unwrap in this context.

I think it's also perfectly reasonable to use in a context like binary you run locally for private consumption, or for instance a serverless function which allows you to pinpoint the source of errors more easily in the logs.

It's not a good fit for cases where you do expect cases where the unwrap will fail, but it's a great fit for cases where you believe the unwrap should always succeed, as it allows you to pinpoint the cases where it fails.

[tialaramex]

I call unwrap a lot in unit tests where it feels obvious to me that this succeeds, so, if it doesn't that's a huge mistake and should definitely fail the test but I have no pre-existing description of what's wrong, it's just a big red flag that I'm wrong.

Fallible conversions that never fail in the tested scenario are an example - parsing "15/7" as a Rational is never going to fail, so unwrap(). Converting 0.125 into a Real is never going to fail, so unwrap(). In a doctest I would write at least the expect call, because in many contexts you should handle errors and this shows the reader what they ought to do, but in the unit test these errors should never happen, there's no value in extensive handling code for this case.

[wiktor-k]

> I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.

Take a closer look at testresult since it also points directly at the exact line of failure (due to panics being used under hood) but looks nicer.