Migrating A Mocha project to Jest Test Framework

Migrating A Mocha project to Jest Test Framework

I like mocha just like the next guy, but sometimes it's time to move on. We're talking about iced coffee, right?


The Why

So I actually had a chance to take the Jest testing framework for a drive in a side-project that abstracts some Amazon AWS S3 functions: https://github.com/lirantal/aws-s3-utils, but this story is about migrating an existing project to Jest.

The story is about an old library I built that converts a Linux CRON scheduling notation to Quartz format. I named it in the most creative way I could: cron-to-quartz: https://github.com/lirantal/cron-to-quartz

fun fact #1 - cron-to-quartz is the first, and only library on npm that does this conversion!

I used mocha and should.js for tests, and I also cared to integrate security through tools like Snyk to watch over dependencies which might introduce vulnerable code so I know to upgrade or patch them.

If you add a project badge on your README it's easy to notice:

The vulnerability is coming from mocha, and one could argue that it's just a testing framework and doesn't ship out to users. That's true, but it bothers me none-the-less and I'm crazy like that.

You can read more about this vulnerability: https://snyk.io/vuln/npm:growl:20160721


The Big Migration

Jest makes it easy to migrate away from test runners like mocha, or from using assertion libraries like should.js. It does this by employing codemods which are amazing but deserve their own post, but in short they work like babel - reading your test code and converting it to Jest code.

Codemods

Install the jest-codemods library as a global tool that you can run on any project or codebase:

yarn global add jest-codemods

When you execute the jest-codemods utility it will interactively prompt you to select which frameworks you are using so it can run the correct combination of codemods under the hood to migrate your project:

It's possible to do a dry run of the migration where you aren't actually changing your code-base and you can survey how the process works out and what manual intervention you possibly need beyond the codemods automatic migration.

Not all roses and rainbows

The conversion worked almost perfectly except the AST plugin didn’t handle chained should.js assertions properly so it ended up with expect assertions that aren’t valid and all the test actually failed.

It’s not that bad either.

I quickly updated the existing should.js test code to refactor out the chained assertions:


Then running the codemod conversion and it’s done!

From Mocha to Jest in seconds.

At this point on as simple as removing mocha and should.js dependencies and replacing them with jest and updating the project accordingly.

A Little Jem For Closing

If you reached this far I thought I’d treat you with a little gem for closing:

Fun fact #2 — did you know there’s an actual movie titled  Mocha & Chai?


Can’t wait for your comments with feedback on the movie!

Liran Tal

Lead DevRel & Secure Coding advocate ??

7 å¹´

Cool! Thanks for sharing. What were you using before Jest? also Mocha?

赞
回复
Bryan Jacquot

Google Cloud Engineering Leader

7 å¹´

We switched to Jest about a year ago in Grommet and haven’t looked back. Now using it in production apps as well. https://blog.grommet.io/post/2016/09/01/how-we-landed-on-jest-snapshot-testing-for-javascript

要查看或添加评论,请登录

Liran Tal的更多文章

  • You think your React application is secure? Think again

    You think your React application is secure? Think again

    I had an awesome time presenting at ReactNext Conference 2021 ?? Here are some thoughts from me on why it was different…

    1 条评论
  • Meet the Node.js Security Working Group

    Meet the Node.js Security Working Group

    In this post I would like to acquaint you with the work being done by the Node.js Security Working Group and how we’re…

  • Scalable Integration Testing for Microservices deployments

    Scalable Integration Testing for Microservices deployments

    Many jumped the gun on microservices, and they are ubiquitous today more than ever for implementing service oriented…

  • Securing a Node.js + RethinkDB + TLS setup on Docker containers

    Securing a Node.js + RethinkDB + TLS setup on Docker containers

    Intro We use RethinkDB at work across different projects. It isn't used for any sort of big-data applications, but…

  • Wiring up Ava.js Integration Tests with Express, Gulp, but not Supertest.

    Wiring up Ava.js Integration Tests with Express, Gulp, but not Supertest.

    Gulp, the streaming build system for JavaScript source code probably doesn't require an introduction, and most probably…

  • 3 Things You Didn't Know About Yarn

    3 Things You Didn't Know About Yarn

    Everyone talk about Yarn's speed and reliability but no one mentions any of the below nice-to-know facts about Yarn. 1.

  • Node.js Yarn'ing for Local Packages

    Node.js Yarn'ing for Local Packages

    This is not another praise for npm package management with Yarn but rather a concise recipe for working with locally…

    2 条评论
  • Hidden features of Gulp for integration tests with Ava.js.

    Hidden features of Gulp for integration tests with Ava.js.

    This is a bit of a follow-up to my previous post on Wiring up Ava.js Integration Tests with Express, Gulp, but not…

  • The JavaScript Test Runners Evolution

    The JavaScript Test Runners Evolution

    Like with everything else in the JavaScript ecosystem, test automation tools are also going through a high pursuit…

    3 条评论
  • Keep on Babeling with?ES6

    Keep on Babeling with?ES6

    Keep on Babeling with ES6 In my previous post we did a crash course to Babel.js, let’s now dive deeper down the rabbit…

社区洞察

其他会员也浏览了