cc imeredith this might be worth researching too

cliffmeyers IVan did some reasearch on this and was going to write it up. The start of the art for unit and integration testing of react apps is not terribly impressive it seems, would be good to get your feelings on it too. I am sure we can do better. 

Couple of useful reads I found over the weekend that seem to be pro-Jest:
https://www.codementor.io/vijayst/unit-testing-react-components-jest-or-enzyme-du1087lh8
https://blog.grommet.io/post/2016/09/01/how-we-landed-on-jest-snapshot-testing-for-javascript

And at least one contrarian opinion:
https://www.reddit.com/r/reactjs/comments/46cwj3/whats_february_2016s_best_alternative_to_jest_i/

I am not sold on it, although I do think it might be worth taking a look at. Happy to discuss more.

Perhaps rather than pure unit tests we could also look at "integration tests" where we mock out HTTP calls using nock. That could give us a lot more confidence that certain views are behaving appropriately when wired up to a more real world plumbing.

This is very much related to JENKINS-43671

cliffmeyers yes - by "unit tests" really means "not end to end" - it may mean "integration" tests, for sure. 

Without a deep understanding of React testing (I come from an angularJS 1.x shop) I'd say that it's always a safe bet to chose the framework which maintained by the principal contributors to the project. In this case Facebook -> Jest.

The Jest team has a healthy community which continually addresses issues and has specifically solved the issue which affected the user from feb 2016 in addition to a bunch of other first-time-user issues.

Jest looks good - but I will let cliffmeyers comment. When I looked it was about snapshot based testing which seems "odd" to me and not sure if it really helps people that much in practice (it just tells you that "things have changed") and encourages people to churn the tests all the time, vs writing things that are less variable with small changes. 

jhill thanks for that feedback. There are a few parts to Jest really, that need to be considered independently:

• Jest is a test runner, which would replace the mocha runner (used by jenkins-js-builder) or the karma runner (used in some libs like JDL or blueocean-core-js). Jest runs in a browserless environment which has pros and cons. We don't have too many issues with the test runner itself, although it would be good to standardize on one across the board.
• Just has some auto-mocking behavior which is interesting but also very complex under the hood.
• Jest offers an API to do snapshotting which is optional; you can also use Enzyme w/ react-test-utils like we do today in most unit tests. The thrust of this ticket was mostly on this point here, as to whether it would better than Enzyme shallow render. Enzyme's html() method should also be explored.

Added link to the PR. As it stands now it accomplishes the following:

• Switch to Jest test runner for core-js standalone gulp build and dashboard / personalization via js-builder plugin.
• Outputs coverage reports for all
• Outputs junit test reports for all
• Allows unit tests to be easily debugged

Does not address improvement of test coverage in any particular place, but this should give us the tools to do that.