Expose more data in reporters for IDE integrations

@SimenB Great! Regarding benefits of using Jasmine reporter, I don’t have a complete list unfortunately. Some of them I could recall:

• An implication of sending events about describe/test/it: it allows to attach output to correct node in a test tree, and, when debugging, you can see live output of console.log/process.stdout.write.
• Failed assertions provide separate compact error messages and error stacks whereas Jest reporter provides a single merged error message+stack making it’s hard to show a compact error message for a failed element in the editor. It’d be great to provide separate values: expected/actual/message/stack.

_Originally posted by @segrey in https://github.com/facebook/jest/issues/8118#issuecomment-472505276_

[SimenB]

@sauravhiremath @kunal-kushwaha you can probably do the first part of this at the same time as https://github.com/MLH-Fellowship/jest/pull/32 etc

[SimenB]

That’s wonderful @G-Rath, thank you!

An implication of sending events about describe/test/it: it allows to attach output to correct node in a test tree, and, when debugging, you can see live output of console.log/process.stdout.write.

This is essentially #6616, so if you wanna work on that, I’d start by taking a look at #9001 and break it up into smaller parts we can land separately.

@rogeliog has already listed the 4 things it does in the OP - I’d break them all out into separate PRs. I’d personally do it in the order 2, 1, 3, 4 since they all build upon one another. 2 and 1 are not dependent on one another, but 3 and 4 depend on both of them, and 2 is the change I think will be easiest to land. Happy to discuss these further if you want (feel free to open separate issues, or just fork #9001, rip out the parts you don’t need, and open up a PR with that for discussion).

Failed assertions provide separate compact error messages and error stacks whereas Jest reporter provides a single merged error message+stack making it’s hard to show a compact error message for a failed element in the editor. It’d be great to provide separate values: expected/actual/message/stack.

This should be way easier so I recommend tackling this first - it’s “just” exposing more data on the AssertionResult object: https://github.com/facebook/jest/blob/084508290f4a90b28c3190021d3358ab1f753c3f/packages/jest-test-result/src/types.ts#L60-L70

failureMessages is an array of strings here, we should probably add something more structured (while avoiding a breaking change, so we need a new property)