Any best practices for testing with Jest?

I’m using Jest as a test framework. My naive attempts at writing tests for functions that return a Result typically look like:

expect(callSomeFunction("with", "some", "args")).isOk()).toEqual(true);
expect(callSomeFunction("with", "some", "args"))._unsafeUnwrap()).toEqual(someExpectation);

This is a bit clumsy because:

• I need to double all test calls just for the isOk() and _unsafeUnwrap() parts. Especially if the callSomeFunction("with", "some", "args") expression is long, this causes quite some overhead.
• When the function fails, the runner only outputs that isOk() wasn’t true. Any helpful information in the error object remains hidden. I frequently copy paste the expression into a third line for an ad-hoc console.log just to get some information, which of course feels wrong 😉.
• Using _unsafeUnwrap and _unsafeUnwrapErr basically everywhere looks a bit ugly and feels like an anti-pattern.

I’m be no means a Jest expert and still have to check if it offers something that could help here.

I just wanted to bring up the topic, perhaps there are already some better approaches?

[bluenote10]

Cool, thanks for all the fixes.

To summarize the best practices for future readers here: After the changes it is now possible to simply “bring the ok / err to the other side”, i.e.:

expect(callSomeFunction("with", "some", "args")).toEqual(ok(someExpectation));

Alternatively this can be used:

expect(callSomeFunction("with", "some", "args")._unsafeUnwrap()).toEqual(someExpectation);

Both approaches should now print very good error messages if a test case returns an ok where an err is expected or vice versa.

Now that this works, I would advice against using a combination of

expect(result.isOk()).toBe(true);
expect(result.value).toHaveProperty("foo");

Not only does it bloat the test code unnecessarily, but it also hides the crucial failure information behind an uninformative false was not true failure stemming from the isOk() check.

[supermacro]

Here’s a proposed non-breaking change that would allow for generating stack traces in the event that these methods are being used outside of tests and a caller wants stack traces:

https://github.com/supermacro/neverthrow/pull/217/files