Expose more data in reporters for IDE integrations

[SimenB]

@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 #8118 (comment)

[G-Rath]

@SimenB I'm keen to scope out what this'll take implementation-wise, if you've got some time :)

[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)

[G-Rath]

@SimenB thanks for that amazing detailing - that's perfect for me to begin actioning.

I'll definitely start with adding the new property on AssertionResult, and then look to break up that PR.

[SimenB]

@sauravhiremath @kunal-kushwaha you can probably do the first part of this at the same time as MLH-Fellowship#32 etc

[vitalii7777]

@SimenB @G-Rath

WebStorm

Still have not found logs (console logs or console warns) that belong to it or test blocks (only failure messages works well). All logs are gathered to one long list and belong only to describe block.

At the same time logs works perfectly with jest-jasmine2