Expect to jest transformer

[skovhus]

@mjackson https://www.npmjs.com/package/expect is being integrated into Jest. This codemod automates the upgrade path. It is extending the work started in cpojer/js-codemod#66

Background: jestjs/jest#1679

/cc @cpojer

Step 1

• add initial codemod from https://github.com/cpojer/js-codemod/blob/master/transforms/expect.js by @vjeux
• messages from all matchers should be removed as some of them actually break Jest (e.g. expect(object).toExist('remove me'))
• warning on usage of chained expect calls
• remap non standard named expect import/require name
• add more test cases
• warn about comparator optional argument of toInclude and toIncludeKeys that is left but ignored by Jest
• spyOn calls Use the "expect" npm package jestjs/jest#1679 (comment) and Use the "expect" npm package jestjs/jest#1679 (comment)
• • andCall andReturn andThrow (createSpy and spyOn)
• • andCallThrough not supported in Jest?
• • spy.calls[i].arguments[j] -> spy.mock.calls[i][j]
• • spy.calls.length -> spy.mock.calls.length
• • restoreSpies and resetSpies
• • warn about isSpy is missing from Jest
• • import expect, { createSpy, spyOn, isSpy } from 'expect' warning
• when running in standalone mode, running the transformer twice on the output shouldn't break or change anything (as expect will be used for both expect@1 and the new Jest version, we cannot import detect).
• toMatch can also be on objects, so cannot be translated 1:1 with Jest toMatch... See https://github.com/mjackson/expect#tomatch (maybe toMatchObject?) and https://github.com/ReactTraining/react-media/pull/61/files/886826394d672a721b7decaab3831d4af9d9177a#r124528600
• expect allow expect argument to be undefined, Jest doesn't (example: expect(node.firstChild.innerHTML).not.toMatch(/hello/) from react-media)
• ensure all matchers from expect are covered (or a warning is logged for unsupported features)

Step 2

• try the codemod out on mjackson's or ReactTraining projects
• • react-router Use jest-matchers for assertions instead of expect remix-run/react-router#5027
• • history Use jest-matchers for assertions instead of expect remix-run/history#468
• • react-media Use jest-matchers for assertions instead of expect ReactTraining/react-media#61
• • fix failures due to jest-matchers contains untranspiled code jestjs/jest#3360
• consider if other transformers in jest-codemods would benefit form the standalone mode option (being able to run in node)
• document standalone mode
• document steps to do after codemod has run
• figure out if package is called expect or jest-matchers

Bugs

• console.error does't have calls property when using jest spies:

  it('warns when passed a history prop', () => {
    const history = {}
    const node = document.createElement('div')
    expect.spyOn(console, 'error')

    ReactDOM.render((
      <MemoryRouter history={history} />
    ), node)

    expect(console.error.calls.length).toBe(1)
    expect(console.error.calls[0].arguments[0]).toMatch(
      /<MemoryRouter.*import \{ Router }/)
    expect.restoreSpies()
  })

[mjackson]

Thank you, @skovhus :) How can I try this out? I'm not familiar with how to run a code mod. Is there a doc somewhere?

[skovhus]

Hi @mjackson.

I'll update you when the codemod is ready. But this repo has a little CLI that should make it fairly easy to run on an existing codebase. It wraps jscodeshift. See https://github.com/skovhus/jest-codemods#usage-cli

But I might try the codemod out on some of your repos with expect. ; )

[skovhus]

@mjackson for projects like React History and React Router it seems that you guys are using Expect+Karma+Mocha to execute your tests in Chrome or other browsers.

As Jest is executed in node only, these projects might not be good candidates for testing this codemod. Unless if you are interested in switching to a node only test environment? Let me know what you think : )

[cpojer]

This is fantastic.

@skovhus The new version of expect must definitely also be made to work on the web. So this codemod should enable people to switch from the previous version of expect to the new version. One way to try that out would be to run the codemod on react history/react router and then add jest-matchers and change const expect = require('jest-matchers') and make sure that works in the browser.

We may have to provide a single-file build for jest-matchers, that's still to be decided.

The idea is to ship this breaking change sometime in mid April.

[skovhus]

Thanks for the input! So essentially two uses cases: for upgrading expect and for upgrading to use Jest as test runner.

The output of these two cases can be made compatible if we leave the jest-matchers input in there.

So if we import expect from jest-matchers even for users just running on node... that might make sense, as we don't need two codemods or configuration.

[cpojer]

Hmm, here would be my recommendation:

• Transform with Jest:
• expect.spyOn => jest.spyOn, expect.spy => jest.fn
• require('expect') gets removed.
• Transform without Jest:
• expect.spyOn => mock.spyOn, expect.spy => mock.fn by including jest-mock.

The module jest-matches will be renamed to expect, so the require statement does not need to changed. Inside of Jest, we don't need to require it because it is globally available.

[skovhus]

Two codemods (or configuration) it is. 👍🏻

[cpojer]

btw. this plugin should help insert requires for the second one: https://github.com/cpojer/js-codemod/tree/master/extensions/imports

[brantphoto]

hi @skovhus I'm excited to use this codemod. We'll be using this exact scenario to move to Jest at my work. Thanks for making it!

[skovhus]

@brantphoto so happy to hear that! : )

I'll let you know when you can try it out. 👍

[skovhus]

Standalone mode is a bit blocked on jestjs/jest#3360

[cpojer]

Hey Kenneth! What's the status of this PR? Are you going to merge it? Except for the blocker inside of Jest, is there anything else left that we need to do?

[skovhus]

Nope. Planning to merge it when the standalone mode works for React Router.

Everything else should be fine. 😀

[skovhus]

@cpojer is the plan still to rename jest-matchers to expect (and release as version 2)?

Do we want to do that before this codemod goes out? Or should we just change this codemod to migrating from expect@1 to jest-matchers?

[cpojer]

We'll publish expect@20 or @21, yes. I'm not sure when yet, but that's the plan.