a. I am. I'm the only one working on this product so far, so I haven't run into the issue of it being exotic. I test my components, actions, data stores, api util, and misc util modules completely separately though. I have run into the issue of "oh, it's failing because that thing that's mocked is returning undefined instead of an empty array", but that just means I need to test for undefined behavior :)
Everything in my ./node_modules is unmocked, though.
On a previous project, we used karma+jasmine and the mocking became extremely cumbersome very quickly. Setup/teardown for a given module was up to 5-10x longer than the actual tests for said module. It might have been an artifact of applying unit tests to a codebase that was never tested properly before (and then not having time to refactor).
b. It 'just worked' for me. I'm happily generating lcov / clover reports with jest 0.4.17 `jest --coverage`. I even have it in my continuous build setup, so my coverage reports update every time I save. There's weirdness where it will report a branch or function as ignored, and I can't find which branch that is ... but I think that may be an ignored/missed function in the transpiled source (I work in ES2015).
c. Yes. And I love them. Default setup is to run these in JSDom (headless). We're considering doing full end-to-end tests with selenium in an e.g. jenkins environment, but haven't come to a decision yet - as much of that testing would be duplicating the already-written component unit tests.
It is slowing down a little bit. My test suite takes 21 seconds to run right now (including coverage analysis), which is pretty slow considering the number of components I have. Some of the async modules run even slower, though - it hasn't been a sticking point so far, but it will be fairly soon. Average test per component is ~3 seconds, with the longest taking 10 seconds. Test suite runtime doesn't grow linearly, though: average component test is 5.34s; average non-component test is 0.8s; total time taken by tests is 63s; actual (perceived) time for the entire test command including webpack build is 21 seconds.
c. jsdom, yeah, thanks! Maybe you're used to longer tests and are okay with it; I got spoiled by the early test suite of this project running in one or two seconds, which enabled me to tell my editor to automagically run tests at each save and report brokenness (in Atom, with the test-status package [1]). Which is amazing, almost physical, because it lets you feel when you break stuff and when you're back in a stable state. Then we discovered the jsdom tests, and at this point we didn't have any end-to-end Selenium tests, so it sounded like a great first step and we added them, but liiittle by little they started lengthening the tests, to a point where I abandoned my auto-test setup. Maybe this auto-test looks futile to you, to me it's the kind of enabling real-time dev. experience I now want to replicate on all the projects I work on, like react-hot-loader [2].
Everything in my ./node_modules is unmocked, though.
On a previous project, we used karma+jasmine and the mocking became extremely cumbersome very quickly. Setup/teardown for a given module was up to 5-10x longer than the actual tests for said module. It might have been an artifact of applying unit tests to a codebase that was never tested properly before (and then not having time to refactor).
b. It 'just worked' for me. I'm happily generating lcov / clover reports with jest 0.4.17 `jest --coverage`. I even have it in my continuous build setup, so my coverage reports update every time I save. There's weirdness where it will report a branch or function as ignored, and I can't find which branch that is ... but I think that may be an ignored/missed function in the transpiled source (I work in ES2015).
c. Yes. And I love them. Default setup is to run these in JSDom (headless). We're considering doing full end-to-end tests with selenium in an e.g. jenkins environment, but haven't come to a decision yet - as much of that testing would be duplicating the already-written component unit tests.
It is slowing down a little bit. My test suite takes 21 seconds to run right now (including coverage analysis), which is pretty slow considering the number of components I have. Some of the async modules run even slower, though - it hasn't been a sticking point so far, but it will be fairly soon. Average test per component is ~3 seconds, with the longest taking 10 seconds. Test suite runtime doesn't grow linearly, though: average component test is 5.34s; average non-component test is 0.8s; total time taken by tests is 63s; actual (perceived) time for the entire test command including webpack build is 21 seconds.