--- title: consistent-data-testid rule description: Understanding the errors reported by the rule, `consistent-data-testid` isPublicLesson: false --- # `consistent-data-testid` rule :::caution This rule is only compatible with React Testing Library framework. ::: ## Understanding the rule The `ByTestId` queries should be avoided at all cost and used only as a last resource. However if, for whatever reason, you need to use them in your code base, this rule will allow you enforce a consistent format for the `data-testid` attribute. That's the reason this rule is a bit special; instead of reporting errors in your test files, `consistent-data-testid` will complain about code violations in your component files. The idea is to pass a Regular Expression to the rule, so all the values set in the `data-testid` attribute of your components follow a pattern. The rule won't encourage to follow a default pattern out of the box, so it's up to you to decide the RegExp to set to make your `data-testid` homogeneous (we will see more about this in the [Options](#options) section). When `consistent-data-testid` rule reports an error, you'll see the following message: > `{ data-testid-attribute }` "{ data-testid-value}" should match `{ testid-pattern }` ## How to fix the errors reported There is no straightforward instruction about how to fix the code violations reported by this rule. **All you need to do is to rewrite the value set in `data-testid` attribute until it matches the given pattern**. Let's see this with an example. We have enabled the rule with the following config: ```json { "rules": { "testing-library/consistent-data-testid": [ "error", { "testIdPattern": "^{fileName}(__([a-z-]+)+)*$" } ] } } ``` You can see we have used the following pattern: `^{fileName}(__([a-z-]+)+)*$` (we will see more about the `{fileName}` placeholder in the [Options](#options) section). This means that the values within `data-testid` must match that pattern which is: name of the file + `__` + some string in kebab-case. Having this pattern in mind, take a look at our test example: ```javascript { actualFilename=protected/demo-app/src/lesson/example.test.jsx endChar=238 endLine=9 startChar=0 startLine=1 url=https://gitlab.com/fullstackio/books/master-writing-testing-library-tests-using-eslint-plugin-testing-library/module_04/lesson_04.03/protected/demo-app/src/lesson/example.test.jsx } import React from 'react' import { render, screen } from '@testing-library/react' import { App } from '../App' it('should render a basic demo', () => { render() expect(screen.getByTestId('MainHeading')).toBeInTheDocument() }) ``` The test is passing and there are no ESLint errors reported! However, we mentioned that this rule won't point out code validations in your test file but your component file, right? Let's open the `App.jsx` component then: ```javascript { actualFilename=protected/demo-app/src/App.jsx endChar=2091 endLine=83 startChar=101 startLine=5 url=https://gitlab.com/fullstackio/books/master-writing-testing-library-tests-using-eslint-plugin-testing-library/module_04/lesson_04.03/protected/demo-app/src/App.jsx#L5 } export const App = () => { const [secondsOpen, setSecondsOpen] = useState(0) const [clicksCount, setClicksCount] = useState(0) useEffect(() => { const timer = setInterval( () => setSecondsOpen((prevSecondsOpen) => prevSecondsOpen + 1), 1000, ) return () => clearTimeout(timer) }, []) const handleCountReset = (event) => { if ( event.code === 'Enter' && event.target.value.toLowerCase() === 'reset' ) { setClicksCount(0) setSecondsOpen(0) } } return (

Hello Parcel + React!

Edit App.jsx and save to test HMR updates.

Page has been open for {secondsOpen} seconds.

Write "reset" and hit enter to reset all the counts: