1) Unit test (no-render components): mocha/titef
2) Unit tests (render components): jest + enzyme
3) Integration tests: jest + enzyme
4) E2E: wdio (with mocha)
I am the author of titef*, so 1) can be biased. In 2) I am taking in account snapshot testing. In 3) I am talking about integration between components.
Excluding titef, I'd use mocha for pretty much everything, but snapshots are extremely convenient, especially when you need to deliver fast. Bottom line, my decision tree goes pretty much like:
small project, mostly visual, no much logic -> jest + enzyme and mostly snapshot tests
small project, lots of logic, dumb or not-so-relevant UI -> mocha (+ enzyme eventually) and mostly unit tests
medium project worth a double setup -> mocha, jest + enzyme and unit tests with snapshots
big project -> all the above
*: The reason why I started titef was that jest is incredibly slow, but I love snapshot testing. I didn't finish it yet, so right now it's just a faster mocha.
Pawan is working as Sr Web developer at JCP, loves to make impact to the customers or masses, comfortable throughout the stack, but presently making difference at front end and devtools.
1) Unit test (no-render components): mocha/titef
2) Unit tests (render components): jest + enzyme
3) Integration tests: jest + enzyme
4) E2E: wdio (with mocha)
I am the author of titef*, so 1) can be biased. In 2) I am taking in account snapshot testing. In 3) I am talking about integration between components.
Excluding titef, I'd use mocha for pretty much everything, but snapshots are extremely convenient, especially when you need to deliver fast. Bottom line, my decision tree goes pretty much like:
*: The reason why I started titef was that jest is incredibly slow, but I love snapshot testing. I didn't finish it yet, so right now it's just a faster mocha.
Interesting.