Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expect dies with "ReferenceError: Element is not defined" in "node" test environment #7786

Closed
mfeineis opened this issue Feb 3, 2019 · 7 comments
Labels

Comments

@mfeineis
Copy link
Contributor

mfeineis commented Feb 3, 2019

🐛 Bug Report

When running tests with "testEnvironment": "node" and expect determines via duck typing that it has DOM nodes to compare it throws ReferenceError: Element is not defined since Element isn't available in Node.

To Reproduce

Use "testEnvironment": "node" and run this test

describe("reproduce bug", () => {
    it("should know that inside a 'node' env there is no 'Element' in scope", () => {
        expect({ nodeName: "div", nodeType: 1 })
            .toEqual({ nodeName: "div", nodeType: 1 });
    });
});

The most likely culprit in my opinion is this region where it was determined per duck typing that the things to compare are DOM nodes and then an unguarded instanceof Element check is run https://github.com/facebook/jest/blob/master/packages/expect/src/jasmineUtils.js#L134

Expected behavior

It should always check that Element or any other host object is defined before it is used - so the test above should be green.

Link to repl or repo (highly encouraged)

https://repl.it/repls/PureFrightenedIntegers

Run npx envinfo --preset jest

Paste the results here:

> npx envinfo --preset jest
npx: installed 1 in 3.224s

  System:
    OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 6.7.0 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.0.0 => 24.0.0 
@SimenB
Copy link
Member

SimenB commented Feb 3, 2019

Wanna send a PR for it?

/cc @pedrottimark

pedrottimark pushed a commit that referenced this issue Mar 1, 2019
… (clean cherry pick version) (#7995)

* Check for existence of `Element` when comparing DOM-nody-things (#7786)

* Fall back to deep equality for presumed DOM nodes if `Element` is not in scope (#7786)

* Remove IE<9 specific fallback DOM node comparison (#7786)

* Check for global DOM `Node` in `isDomNode` (#7786)

In a real browser and JSDOM the check will use DOM-Level-3 `Node.isEqualNode`
and for everything else a deep equality check should do the trick.

* Check that `isEqualNode` is a function and remove duck typing from `isDomNode` (#7786)

* Add changelog entry for streamlined DOM node comparisons in `expect` (#7786)

* Correct visible PR number in CHANGELOG.md
@postb99
Copy link

postb99 commented Jan 23, 2020

This code in vue-test-utils.js fails (@vue/test-utils 1.0.0-beta.31). Just installed today released jest 25.1.0 and ts-jest 25.0.0 with vue-jest 3.0.5 (latest)

function polyfill() {
  // Polyfill `Element.matches()` for IE and older versions of Chrome:
  // https://developer.mozilla.org/en-US/docs/Web/API/Element/matches#Polyfill
  if (!Element.prototype.matches) {
    Element.prototype.matches =
      Element.prototype.msMatchesSelector ||
      Element.prototype.webkitMatchesSelector;
  }
}

@SimenB
Copy link
Member

SimenB commented Jan 23, 2020

This was fixed in #7995 (included in 24.3.0), and we just forgot to close this issue.

@postb99 could you please open up a new issue with reproduction steps? https://repl.it/repls/PureFrightenedIntegers does not reproduce using 24.9.0 or 25.1.0 for me, so I think your issue is different somehow.

@SimenB SimenB closed this as completed Jan 23, 2020
@postb99
Copy link

postb99 commented Jan 23, 2020

@SimenB Thanks. I just fixed it... By installing jsdom-global as stated here: https://vue-test-utils.vuejs.org/guides/#choosing-a-test-runner despite it should have been set up automatically.

So I may open an issue but I think I misread something in documentation... How to find the culprit ?

So the relevant packages for my setup are these ones. I write .vue components using typescript, and now Jest runs the test fine. The test code is also written in ts.

"devDependencies": {
    "@babel/plugin-transform-modules-commonjs": "^7.8.3",
    "@types/jest": "^24.9.0",
    "@types/jsdom": "^12.2.4",
    "@vue/cli-plugin-babel": "^4.1.2",
    "@vue/cli-plugin-typescript": "^4.1.2",
    "@vue/cli-plugin-unit-jest": "^4.1.2",
    "@vue/cli-service": "^4.1.2",
    "@vue/test-utils": "^1.0.0-beta.31",
    "babel-core": "^7.0.0-bridge.0",
    "babel-jest": "^25.1.0",
    "jest": "^25.1.0",
    "jsdom": "^16.0.1",
    "jsdom-global": "^3.0.2",
    "ts-jest": "^25.0.0",
    "typescript": "^3.7.5",
    "vue-jest": "^3.0.5",
    "vue-template-compiler": "^2.6.11"
  }

jest.config.js:

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node',
    // before the test framework is installed
  setupFiles: ['./src/__mocks__/client.js'],
  moduleFileExtensions: ['js', 'jsx', 'ts', 'tsx', 'json', 'vue', 'node'],
  transform: {
    // process `*.vue` files with `vue-jest`
    '.*\\.(vue)$': 'vue-jest',
    // process `*.ts` files with `ts-jest`
    '^.+\\.ts?$': 'ts-jest',
    '^.+\\.(js|jsx)$': '<rootDir>/node_modules/babel-jest',
  },
  moduleNameMapper: {
  '^@/(.*)$': '<rootDir>/src/$1'
  },
  testRegex: '(/__tests__/.*|(\\.|/)(test|spec))\\.(jsx?|tsx?)$',
  testURL: 'http://localhost/8081'
}

client.js :

require('jsdom-global')()

@SimenB
Copy link
Member

SimenB commented Jan 23, 2020

remove testEnvironment: 'node', (or set it to the default jsdom) and then you don't need jsdom-global anymore.

@postb99
Copy link

postb99 commented Jan 31, 2020

This works well and even speeds up my tests, 4 suites of 37 tests run in 7s instead of 10s when testEnvironment is set to "jsdom". I don't know why I missed the best testEnvironment to set in the documentation, In fact I did a copy-paste from a colleague's project, this was not the best idea.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants