Latest version not reporting/suggesting changes on disabled/value attributes

[ricardozv28]

• eslint-plugin-jest-dom version: 3.9.2
• node version: 14.17.6
• npm version: 6.14.15

Relevant code or config

    const button = getByRole('button', { name: 'My Button' });
    expect(button.disabled).toBe(true);

    const input = getByLabelText('My Input');
    expect(input.value).toBe('value');

What you did: run eslint using npm run eslint

What happened: eslint is not reporting suggested changes when using .disabled or .value

Reproduction repository: https://github.com/ricardozv28/eslint-plugin-jest-dom-bug

Problem description: When using the latest versions of the package, eslint won't report on .disabled or .value (I haven't tested the other rules but those are the ones that I caught when adding the plugin to an existing repo at work)

Here is a screenshot of the output of the reproducible projet, it is just showing the ones from eslint-plugin-testing-librarry

downgrading to version 3.6.3 make the errors appear

version 3.6.4 only reports the toHaveValue

Suggested solution:

[G-Rath]

It looks like at least for prefer-to-have-value we currently only support *ByRole:

https://github.com/testing-library/eslint-plugin-jest-dom/blob/ee6af993112ac73a4053294e2e55e7ff2ba926f9/src/rules/prefer-to-have-value.js#L35-L35

@benmonro @MichaelDeBoey do either of you know if there's a reason for that? My understanding is that all the queries return elements, so we should be ok to apply this rule to any of the query methods.

(I'm guessing this is probably also the case for prefer-enabled-disabled but have not found where it's actually doing the check yet)

[MichaelDeBoey]

@G-Rath It seems like this was first introduced by @juzerzarif in #122

[juzerzarif]

I believe it was because ByRole queries are the only ones where we can be definitely sure that the element returned is an input element that has a value attribute (via the role specified). It was a while ago though so @benmonro can correct me if I'm wrong.

[G-Rath]

@juzerzarif that makes sense - in that case if we want to keep it like that we should probably stick a note in the doc; could also be worth considering if we want to provide a loose option for people who'd prefer to risk the false positives.

(I imagine that's the case with a number of rules - could be interesting to see if optionally using type-checking if available could let the rules be smarter)

[benmonro]

Yeah adding a note to the docs makes sense to me

[github-actions[bot]]

:tada: This issue has been resolved in version 5.0.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: