Hmmm... this is good but presumably react components are actually going to do things. But I suppose you're saying that the code that actually does things should be separated from the react code and should be tested separately from the react components.
In a similar vein, I use Storybook to build my presentational components, and run each story in a try/catch to check for "explosions".
If you add some dependency injection to look for `console.warn` or `console.error` calls, you can catch failed PropTypes or similar.
Today you can even combine all of these with Jest's new "Tree Snapshot Testing" to compare the actual output of `render` with an expected/approved output.
Finally, you can use your stories in combination with a service like Browserstack or SauceLabs to run these tests across platforms, and even take screenshots of each story and compare them to test for styling regressions and cross-platform differences.
2 comments
[ 1.0 ms ] story [ 15.0 ms ] threadIf you add some dependency injection to look for `console.warn` or `console.error` calls, you can catch failed PropTypes or similar.
Today you can even combine all of these with Jest's new "Tree Snapshot Testing" to compare the actual output of `render` with an expected/approved output.
Finally, you can use your stories in combination with a service like Browserstack or SauceLabs to run these tests across platforms, and even take screenshots of each story and compare them to test for styling regressions and cross-platform differences.
Sources:
Storybook - https://github.com/kadirahq/react-storybook
Jest's "Tree Snapshot" testing - https://facebook.github.io/jest/blog/2016/07/27/jest-14.html