+
+// Test.ts
+const component = getByRole("custom-role");
+```
+
+#### Testing ID
+
+Another option, you have to access any tags in a component is to add `data-qa` prop.
+
+To add a data-qa attribute to elements in your components and access those elements in your tests using `@testing-library/react`, you can follow these steps:
+
+1. Add data-qa attributes to elements: In your component's TSX code, add the `data-qa` attribute to the elements you want to target in your tests. Assign a meaningful value to the attribute that helps identify the purpose or role of the element.
+
+```ts
+const BackgroundImage = (props: WithChildren
) => {
+ const {qa} = props;
+
+ return {/* Other components */}
;
+};
+```
+
+2. Access elements using data-qa attributes: Use the `getByTestId` or other query methods provided by `@testing-library/react` to access the elements based on their data-qa attributes.
+
+```ts
+const submitButton = getByTestId('background-image');
+```
+
+It is possible to change `data-qa` dinamically:
+
+```ts
+const BackgroundImage = (props: WithChildren) => {
+ const {qa} = props;
+
+ return {/* Other components */}
;
+};
+```
+
+#### Avoid Direct Node Access
+
+Avoiding direct Node access in testing is essential for several reasons. Testing Library methods emulate user behavior, ensuring that tests focus on the actual user experience. They encourage best practices by prioritizing output over implementation details, resulting in more resilient tests. Additionally, using Testing Library methods improves test maintainability by shielding tests from structural changes in components, enhances test readability, and makes tests more portable and reusable. Overall, this approach promotes testing best practices, improves maintainability, and ensures effective tests as your codebase evolves.
+
+It is important to avoid direct Node access when writing tests. This means refraining from using methods like `querySelector` or `querySelectorAll`. Instead, we should rely on testing library methods such as `getByRole`, `getByText`, or `getByTestId` to access components.
+
+In some cases, the prop being tested may have an impact on a deeply nested container within the component. It can be tempting to access this container using `querySelector` or similar methods. However, it is advised to resist this temptation and continue utilizing the recommended testing library methods for accessing and interacting with components.
+
+```ts
+// ⚠️ DO NOT USE
+screen.getByTestId(id).querySelector('p');
+```
+
+⚠️ Engaging in such practices is strictly discouraged, and there are compelling reasons for doing so. You can find detailed explanations regarding the importance of avoiding direct node access and the associated reasons by referring to the documentation available at [avoid-direct-node-access.md](./avoid-direct-node-access.md).
+
+#### Shared Test
+
+✅ Reusing common tests ensures efficiency, consistency, and scalability in software testing, reducing duplication, improving maintenance, and promoting standardized behavior across components.
+
+Testing common props like `className`, `style`, and others is a recurring task that appears in nearly every test scenario.
+
+Shared test implementation:
+
+```ts
+import {testCustomClassName} from './test-utils/shared/common';
+
+...
+
+test('add className', () => {
+ testCustomClassName({
+ component: BackgroundImage,
+ props: {qa: qaId},
+ });
+});
+```
+
+### Tests Development
+
+It is recommended to prefix branch names with `test/...` when working on test-related branches. Additionally, commits and Pull Requests can follow a naming convention such as `test({ComponentName}): test for {ComponentName} added` to clearly indicate the addition of tests for a specific component.