Testing arity of functions no longer works

[nfantone]

🐛 Bug Report

After the introduction of this commit, testing array-like structures and function arities no longer works with .toHaveLength. This used to behave correctly previously.

To Reproduce

Pass in a function as the argument to .toHaveLength

const myFunction = require('./my-function');

test('should return a function of arity 2', () => {
  expect(typeof myFunction).toBe('function');
  expect(myFunction).toHaveLength(2);
});

Test will fail with:

 FAIL  src/feature/my-function.test.js
  ● should return a function of arity 2

    expect(received).toHaveLength(expected)

    Matcher error: received value must have a length property whose value must be a number

    Received has type:  function
    Received has value: [Function myFunction]

Expected behavior

Test should pass. Also the returned error message ("have a length property whose value must be a number") is rather misleading as the argument being passed clearly conforms to that description. This is a breaking change in a minor release.

envinfo

  System:
    OS: macOS 10.15.4
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
  Binaries:
    Node: 12.16.1 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm

[nfantone]

Also, since this was a breaking change introduced as a minor bump in a transitive dependency on the expect package, downgrading jest version to 25.2.7 does not resolve the problem. According to the changelog, 25.2.7 should not contain #9626 - but actually does.

[SimenB]

Did you make sure expect was downgraded? It's in semver range

---

/cc @G-Rath, typeof function has a length property

[SimenB]

@nfantone I'd personally find such an assertion a bit confusing, I'd recommend a toHaveArity that only accepted functions. It shouldn't have broken of course

[G-Rath]

Yeah that's fair enough - sorry about that.

TypeScript knows that functions have .length, so it's just a matter of adjusting the guard.

(I'm looking forward to having in be a guard someday so we can just do 'length' in x for things like this and call it a day 😬)

I'll make a PR.

[nfantone]

@SimenB

Did you make sure expect was downgraded? It's in semver range

I know it is - that's why downgrading jest didn't solve the issue and was surprising. But that's the thing right there: I believe users shouldn't care. We don't typically install expect individually. We use jest as a module. You go to the release notes and you'd expect (no pun intended) things listed there to be true for jest as a tool. Which is not the case even though that's clearly how it is laid out. There is no mention of expect anywhere in there.

I'd personally find such an assertion a bit confusing, I'd recommend a toHaveArity that only accepted functions. It shouldn't have broken of course

I understand where you're coming from. And I agree: having a .toHaveArity matcher would be nice, semantically speaking! But at the end of the day, .toHaveArity would just be a duplicate of .toHaveLength and me and the team don't find that to be confusing at all. The concept of arity and function length are synonymous in the JS world (and have always been); albeit with some quirks.

@G-Rath

Yeah that's fair enough - sorry about that.
TypeScript knows that functions have .length, so it's just a matter of adjusting the guard.

Hey, no need to apologise at all! Great work contributing to an awesome project like jest. Keep at it. And thanks for the PR!

[github-actions]

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.