| > 3. [...] The favored test runner, Jest, provides automocking for dependencies and code coverage analysis. 3/3. Thanks for sharing! A few questions about Jest: a. Are you happy with Jest auto-mocking? How do you keep a team from banging its head on this "exotic" behavior? (Typically, devs would be stuck on a test for a few hours, only to notice they failed to unmock something in the chain being tested). Have you tried the alternative of eschewing Jest and doing vanilla Jasmine, including lots of mocks? b. You mention "code coverage analysis". Is it working now? Last time I used it, it was broken and in need of a dependency (Istanbul) revamp/upgrade. c. Do you do "semi-end-to-end" DOM tests (i.e. those booting a micro Selenium-like browser/js environment [1] and letting you do DOM assertions like `findRenderedDOMComponentWithClass` and others at [2])? Last time I worked with React, the team initially loved the ability to do those (as an in-between of unit tests & real end-to-end tests) but after adding a bunch of them, tests took 2min to run instead of 2s, and we were considering removing/splitting them. [1] Don't quote me on that, I have no idea how these environments work but it's certainly not Selenium :P . BTW, can anyone detail the machinery / underlying engine making those work? [2] https://facebook.github.io/react/docs/test-utils.html |
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.