davidcalhoun / eslint-plugin-test-selectors Goto Github PK

Hi! As I told you before, thank you for a great plugin.

There is one thing that I haven't noticed earlier (it's only mentioned in the changelog) but become a big deal now. AFAIK there is no way to disable the auto-fix option per plugin on the .eslintrc level by design. Many projects have lint-staged with eslint --fix option, or auto fix enabled on save in IDE, and the last thing you want to see in the codebase is a random unconfigurable testid :(

It's a big no-go for adoption :/

cc @bkonuwa @pixelbandito

I've added this plugin to our projects with the following settings:

rules: [
"test-selectors/onChange": [
      "warn",
      "always",
      {
        "testAttribute": "data-testid"
      }
    ],
]

Is it possible to set the testAttribute for all rules? Because I don't think there's a scenario where you use a different testAttribute for onChange and for button.

Hi! Thank you for such a useful plugin. There is one thing that confuses me a little bit which is related to testAttribute case insensitivity. For example:

<Button onClick={handleClose} data-testid="cancelButton">Close</Button>

and

<Button onClick={handleClose} data-testId="cancelButton">Close</Button>

Both variants (testid and testId) are treated the same with the following setup: 'test-selectors/onClick': [severity, 'always', { testAttribute: ['data-testid'] }],
Is it expected behavior?

Hi,
I am trying to add this plugin to the angular project (v12). Not successfull as of now.
I extended both angular HTML rule and test selector rule angular rules are working but not the test-selector rules.

In my .eslintrc.json file I added the plugin as recommended by the documentation.

Here is my html

when I run ng lint I am not getting the lint error.

Is there anything else I am missing here?

How open would you be to the testAttribute config property being an array (string or array I guess)? Normally you want to enforce consistency, but here's my reasoning. You can't destructure 'data-test-id' in props because it's not a valid variable name, so I'd love to be able to do this:

// in consumer
<SomeComponentWithAButton dataTest="something" />

// in component
const SomeComponentWithAButton = ({ dataTest }) => {
  <button data-test={`btn-${ dataTest }`}>blah</button>
};

Currently that doesn't work. I'd have to use data-test everywhere, and then in the actual component do something like

({ other, props, ...rest }) => {
  const dataTest = rest['data-test']
}

Either that or an option to turn the rule off for all components and only enforce it on html elements. But I prefer the former cause I do want to enforce dataTest being there.

Hey there,

I was looking to add this to our eslint setup since it supports configuring the name of the attribute, but when I install it and follow the setup in the readme, I get this for every file being linted:

 1:1  error  Definition for rule 'test-selectors/onChange' was not found   test-selectors/onChange
  1:1  error  Definition for rule 'test-selectors/anchor' was not found     test-selectors/anchor
  1:1  error  Definition for rule 'test-selectors/button' was not found     test-selectors/button
  1:1  error  Definition for rule 'test-selectors/input' was not found      test-selectors/input
  1:1  error  Definition for rule 'test-selectors/onClick' was not found    test-selectors/onClick
  1:1  error  Definition for rule 'test-selectors/onKeyDown' was not found  test-selectors/onKeyDown
  1:1  error  Definition for rule 'test-selectors/onKeyUp' was not found    test-selectors/onKeyUp

and it looks like that's because lib/index uses

requireIndex(`${ __dirname }/rules`)

but there isn't an index file in rules (and looking at the requireindex package, it seems like that's how it's intended to be used).

Need to create an optional recommendation set that spits out warnings instead of errors.

Hey all! Thanks for building this up. Very handy extension - we're exploring adopting this, with conjunction of semi-auto-generating test-data-ids with react-id-generator.

One suggestion I had for the current rules is that they are focused on elements which you'd be interacting with (buttons, anchors). The flip side of that is conducting assertions - making sure a certain element contains text (post action or page load). I'm not sure how difficult it would be to add rules for <p>, <span>, <h1> through <h6> and so on.

Once we fully adopt the plugin, I'll give it a spin - but as part of our evaluation of this as a potential solution, this jumped out as a big missing part.

I'm also not sure if there's an easy way to incorporate auto-generation of ids - for most of my elements, I don't care if they're pretty or not, I just want a unique one. If it's commonly used, I'll name it myself, but it'd be great to have a --fix option that just generates random ones / configurable ones. Some documentation on how to wire this up or native functionality would really make this a one-stop-shop for this use case! :)

How to ignore empty value for data-test-id ?

❌ <button data-test-id="">Download</button>
✅ <button data-test-id="download-button">Download</button>

The way this is currently implemented, this needs to be added, but it's missing from the docs:

    "extends": [
        "plugin:test-selectors/recommended"
    ],

Issue

• Large codebase using data-testid rather than data-test-id
• Would like to use this plugin to enforce setting data-testid

Request

• Be able to set data-testid as the target syntax in the settings of this plugin

i find auto-generated ids useful, but it's not great to have a lot of random ids in the codebase. would be nice to be able to configure it, for example so that it takes some kind of combination of component name / file name to generate the id.

I think it would be good to exclude elements with readonly or disabled by default with the ability to turn it on. I am using input's for displaying some non-editable information and this lint rule set errors on them. One other option would be to not error on input without an onChange, but I am not sure which would be better and more robust.