Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tests: Try to migrate server and integration tests to Jest #14364
This PR migrates server and integration tests from Mocha to Jest.
I skipped code coverage for integration tests, because it isn't important at all in this context.
I followed this awesome article to make test helpers work with Mocha and Jest at the same time.
Code coverage result for
Might it be possible to do this more cautiously by introducing jest alongside mocha and then incrementally migrate?
Perhaps we can use a mutually exclusive pattern for test filenames (like 'spec' instead of 'test')
We could introduce and discuss some new tests (specs!) that demonstrate use of jest features (such as snapshots), communicate these more broadly and then start the process for migration once the idea has momentum.
Codemods might then be used to get us the rest of the way.
@markryall thanks for sharing good ideas
I stumbled upon this article https://medium.com/@RubenOostinga/combining-chai-and-jest-matchers-d12d1ffd0303 this week. It helped me to alias Mocha specific lifecycle methods to make them work with Jest. I hope it allows to use Mocha syntax and Jest runner with the client side code, too :)
I don't like the idea of having two different file extensions, because it only makes everything more complicated. I like a lot the rest of suggestion though. It would be nice to be able to run the same tests with Mocha and Jest at the same time, to validate the transition. I'm still not sure if Jest is going to be faster because it initiates testing env for every test suite to ensure they are isolated. It runs tests concurrently, which might make it perform better locally, but it might be no go on Circle CI.
Yes, they are very granular and have interactive mode. So you can migrate everything step by step.
@gziolo that's awesome - if we can just make existing mocha tests work with jest using this aliasing trick then that certainly makes the transition easier.
We'd still have to make the before vs beforeAll change everywhere wouldn't we? That could also probably be handled with some test config. Maybe the same for 'context'.
I'd had performance issues with jest when using it a couple of years ago but we had automocking enabled. I think the useMockery approach we already have for mocks is superior (although less succinct) - jest mocks seem needlessly complicated to me.
Fortunately they disabled automocking last year and introduced several other performance improvements.
There is also a codemod that is able to rename all