This ESLint plugin helps ensure that React components have the necessary data-testid attribute, which is crucial for effective testing of React applications.
yarn add eslint-plugin-react-require-testid --dev
After installation, you need to configure ESLint to use this rule. Here's an example configuration:
{
"plugins": ["react-require-testid"],
"rules": {
"react-require-testid/testid-missing": ["error", {
"disableDefaultComponents": [],
"enableComponents": []
}]
}
}
In this configuration:
disableDefaultComponents
allows you to specify default components to exclude from the rule check.enableComponents
allows you to specify additional components to include in the rule check.
- The rule iterates through JSX opening elements in your code.
- It filters out default React components based on the configuration.
- It merges the filtered default components with any additional components specified.
- For each JSX opening element, it checks if the component is allowed and if it has a
data-testid
attribute. - If the component is allowed but lacks a
data-testid
attribute, a linting error is reported.
Consider the following JSX code snippet:
<MyCustomComponent />
With the ESLint rule configured, it will raise a linting error if MyCustomComponent
is included in the allowed components list but does not have a data-testid
attribute.
Contributions to this ESLint rule are welcome! If you encounter issues or have suggestions for improvements, please open an issue or submit a pull request on GitHub.
This project uses a specification called Conventional Commits, please ensure this specification is followed when commiting code to this project.
Guide: https://www.conventionalcommits.org/en/v1.0.0/
Pull Requests made to this project are required in order to merge to develop or main
When submitting a Pull Request, at least one approval is required before merging.
When constructing a release, ensure that a release branch is created based off of the contents of develop, the only changes contained within this branch should be the version numbers in package.json and android's build.gradle.
The Pull Request should be named as [develop] release vX.Y.Z
Once this Pull Request has been created, you will need to generate a new Pull Request based off main comparing the develop release branch you have just created, this should ensure that all changes that have been made to develop since the last release are contained within this update.
The Pull Request should be named as [main] release vX.Y.Z
Once this has been done and both Pull Requests have been merged, a release tag should be generated, named as vX.Y.Z