Upgrade package @testing-library/user-event from 12.8.3 to 13.5.0 #2468

[mohamedrehan1]

issue: #2468
solve conflict with develop-postgres branch
Upgrade package @testing-library/user-event from 12.8.3 to 13.5.0 and i will work on updating to 14.5.2

Summary by CodeRabbit

Release Notes

• New Features

  • Updated pull request template to prompt contributors to indicate unit or automation tests.
  • Introduced a new job in GitHub Actions to check target branch for pull requests.

• Bug Fixes

  • Enhanced error handling and messaging in workflow jobs for clarity.
  • Improved test robustness across multiple components by refining asynchronous handling.

• Tests

  • Expanded test coverage for user interactions, search functionality, and component behavior in various scenarios.

• Chores

  • Updated @testing-library/user-event dependency to the latest version.
  • Removed outdated configuration files related to IDE settings.

[coderabbitai]

Walkthrough

The pull request introduces several changes, including modifications to the pull request template and GitHub Actions workflow. The template now prompts contributors to indicate whether unit or automation tests have been added and removes details about the branching strategy. The workflow adds a new job to check the target branch and refines existing job conditions and dependencies. Additionally, multiple .idea configuration files are deleted, and the package.json file updates the version of @testing-library/user-event. Various test files have been adjusted to improve asynchronous handling and assertions.

Changes

File Path	Change Summary
.github/pull_request_template.md	Removed section on branching strategy; added prompt for unit/automation tests.
.github/workflows/pull-request.yml	Added Check-Target-Branch job; updated conditions for jobs; refined error handling; updated Node.js version.
.idea/.gitignore	Deleted file, removing rules for ignoring specific files/directories.
.idea/inspectionProfiles/Project_Default.xml	Deleted file, removing inspection profile settings.
.idea/modules.xml	Deleted file, removing project module configuration.
.idea/talawa-admin.iml	Deleted file, removing web module configuration.
.idea/vcs.xml	Deleted file, removing version control settings.
package.json	Updated @testing-library/user-event from ^12.1.10 to ^13.5.0.
src/components/OrgSettings/ActionItemCategories/OrgActionItemCategories.test.tsx	Updated tests for asynchronous handling using await.
src/components/OrganizationScreen/OrganizationScreen.test.tsx	Updated expected class names in tests.
src/components/Pagination/Pagination.test.tsx	Replaced userEvent.click with fireEvent.click for pagination controls.
src/screens/Requests/Requests.test.tsx	Wrapped render calls in await act(async () => { ... }) for better asynchronous handling.
src/screens/UserPortal/People/People.test.tsx	Added assertion for initial empty search input value.
src/screens/UserPortal/Pledges/Pledge.test.tsx	Updated tests for asynchronous handling using await.
src/screens/UserPortal/Posts/Posts.test.tsx	Awaited renderHomeScreen within act function; removed unused import.
src/screens/Users/Users.test.tsx	Expanded tests for search functionality, user not found scenarios, and organization warning alerts.

Possibly related issues

• Upgrade package @testing-library/user-event from 12.8.3 to 14.5.2 #2072: This issue addresses upgrading @testing-library/user-event, which is directly related to the version update in this PR.

Possibly related PRs

• Agenda category CRUD operations #2030: Related to changes in the pull request template and workflow configuration.
• Redesign FundPledge Screen & Add Search/Sort #2040: Connects the pull request template modifications with workflow robustness improvements.
• [Translations] Errors and Success #2078: Aligns with enhancements in error handling and messaging in the workflow.
• Configurable Session timeout for Community #2186: Relevant to improvements in the linting process and developer experience.
• fix: pull-request.yml to ignore actions on ignore-sensitive-files-pr and Introspection workflow #2391: Ties the pull request template updates to better handling of sensitive files in the workflow.
• added docker check to workflow #2414: Links updates in the pull request template with application start checks in the workflow.
• Updated pr template with checklist #2454: Directly related to checklist additions in the pull request template for improved documentation.
• Updated pr template for develop-postgress branch #2458: Ensures consistency across branches, particularly with the develop-postgres branch updates.

Suggested labels

ignore-sensitive-files-pr

Suggested reviewers

• varshith257
• pranshugupta54
• palisadoes

Poem

🐰 In the garden where changes bloom,
A template fresh, dispelling gloom.
With tests that wait and workflows bright,
We hop along, all feels just right!
So let us code, with joy and cheer,
For every change brings us near! 🌼

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[github-actions]

Our Pull Request Approval Process

Thanks for contributing!

Testing Your Code

Remember, your PRs won't be reviewed until these criteria are met:

1. We don't merge PRs with poor code quality.
   1. Follow coding best practices such that CodeRabbit.ai approves your PR.
2. We don't merge PRs with failed tests.
   1. When tests fail, click on the Details link to learn more.
   2. Write sufficient tests for your changes (CodeCov Patch Test). Your testing level must be better than the target threshold of the repository
   3. Tests may fail if you edit sensitive files. Ask to add the ignore-sensitive-files-pr label if the edits are necessary.
3. We cannot merge PRs with conflicting files. These must be fixed.

Our policies make our code better.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them.
When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

[coderabbitai]

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (10)

src/components/OrganizationScreen/OrganizationScreen.test.tsx (1)

Line range hint 1-105: Consider updating test implementation for @testing-library/user-event v13

While the current tests work, the upgrade to @testing-library/user-event v13 offers improved APIs for user interactions. Consider refactoring the fireEvent calls to use the new userEvent API for better simulation of real user interactions.

Example refactor:

 import { fireEvent, render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';

 // Later in the test...
-    const closeButton = screen.getByTestId('closeMenu');
-    fireEvent.click(closeButton);
+    const user = userEvent.setup();
+    await user.click(screen.getByTestId('closeMenu'));

package.json (1)

116-116: Document the upgrade path

Since there's a planned upgrade to version 14.5.2, consider documenting this staged upgrade approach in your project documentation or issue tracker.

Would you like me to help create a GitHub issue to track the future upgrade to version 14.5.2?

src/components/OrgSettings/ActionItemCategories/OrgActionItemCategories.test.tsx (1)

64-67: LGTM! Consider flattening the async assertions.

The changes improve test reliability by properly handling asynchronous rendering. However, we can make this even better by flattening the nested async calls.

Consider this slightly cleaner approach:

-    await waitFor(async () => {
-      expect(screen.getByTestId('searchByName')).toBeInTheDocument();
-      expect(await screen.findByText('Category 1')).toBeInTheDocument();
-      expect(await screen.findByText('Category 2')).toBeInTheDocument();
-    });
+    expect(screen.getByTestId('searchByName')).toBeInTheDocument();
+    await waitFor(async () => {
+      expect(screen.getByText('Category 1')).toBeInTheDocument();
+      expect(screen.getByText('Category 2')).toBeInTheDocument();
+    });

This approach:

1. Immediately checks for the search input which should be available synchronously
2. Uses waitFor only for the dynamic content that needs to be awaited
3. Removes unnecessary nesting of async/await

src/screens/Requests/Requests.test.tsx (4)

56-56: Remove unused mock function call.

The jest.fn() call appears to be unused and can be safely removed.

-jest.fn();

---

Line range hint 137-171: Update userEvent usage for v13+ compatibility.

Since we're upgrading to @testing-library/user-event v13+, we should update the test to use the new async methods and add more assertions:

-    const searchBtn = screen.getByTestId('searchButton');
-    const search1 = 'John';
-    userEvent.type(screen.getByTestId(/searchByName/i), search1);
-    userEvent.click(searchBtn);
+    const user = userEvent.setup();
+    const searchBtn = screen.getByTestId('searchButton');
+    const searchInput = screen.getByTestId(/searchByName/i);
+
+    // Test search for "John"
+    await user.type(searchInput, 'John');
+    expect(searchInput).toHaveValue('John');
+    await user.click(searchBtn);
     await wait();

-    const search2 = 'Pete{backspace}{backspace}{backspace}{backspace}';
-    userEvent.type(screen.getByTestId(/searchByName/i), search2);
+    // Test search for "Pete"
+    await user.type(searchInput, 'Pete');
+    expect(searchInput).toHaveValue('Pete');
+    await user.clear(searchInput);

     // Similar updates for other search interactions...

-    userEvent.clear(screen.getByTestId(/searchByName/i));
-    expect(screen.getByTestId(/searchByName/i)).toHaveValue('');
-    userEvent.click(searchBtn);
+    await user.clear(searchInput);
+    expect(searchInput).toHaveValue('');
+    await user.click(searchBtn);

---

284-313: Add assertions to verify rerendering behavior.

The test case should include assertions to verify the component's state after rerendering.

     await act(async () => {
       rerender(
         // ... existing rerender code ...
       );
     });
     await wait();
+    // Add assertions to verify the new state
+    expect(screen.getByTestId('testComp')).toBeInTheDocument();
+    // Add more specific assertions based on the expected state after rerendering

---

Line range hint 1-316: Consider restructuring tests for better organization and maintainability.

The test file could benefit from:

1. Grouping related test cases using nested describe blocks
2. Extracting common setup code into beforeEach hooks
3. Using test.each for similar test cases with different data
4. Adding stronger typing for mock data

Example structure:

describe('Requests', () => {
  describe('Rendering', () => {
    // Basic rendering tests
  });
  
  describe('Search functionality', () => {
    // Search-related tests
  });
  
  describe('Organization handling', () => {
    // Organization-related tests
  });
});

src/screens/UserPortal/Posts/Posts.test.tsx (1)

Line range hint 367-367: Add act wrapping for consistency

This test case is missing the act wrapping that was added to other test cases. For consistency and proper async handling, consider updating it.

-    renderHomeScreen();
+    await act(() => renderHomeScreen());

src/screens/Users/Users.test.tsx (2)

413-413: LGTM! The assertion improves test coverage.

The added assertion properly verifies that the search input is cleared, strengthening the test case.

Minor typo in the test case name: "Testing seach by name functionality" should be "Testing search by name functionality".

---

Line range hint 1-700: Consider standardizing event simulation methods.

Since we're upgrading to @testing-library/user-event 13.5.0, consider replacing all fireEvent calls with userEvent for consistency and better simulation of real user interactions. The userEvent API provides more realistic event simulation as it more closely mimics actual user behavior.

For example, replace:

fireEvent.click(inputText);

with:

userEvent.click(inputText);

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 6ae40a3 and 0dceb82.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (16)

• .github/pull_request_template.md (1 hunks)
• .github/workflows/pull-request.yml (0 hunks)
• .idea/.gitignore (0 hunks)
• .idea/inspectionProfiles/Project_Default.xml (0 hunks)
• .idea/modules.xml (0 hunks)
• .idea/talawa-admin.iml (0 hunks)
• .idea/vcs.xml (0 hunks)
• package.json (1 hunks)
• src/components/OrgSettings/ActionItemCategories/OrgActionItemCategories.test.tsx (1 hunks)
• src/components/OrganizationScreen/OrganizationScreen.test.tsx (1 hunks)
• src/components/Pagination/Pagination.test.tsx (3 hunks)
• src/screens/Requests/Requests.test.tsx (5 hunks)
• src/screens/UserPortal/People/People.test.tsx (1 hunks)
• src/screens/UserPortal/Pledges/Pledge.test.tsx (1 hunks)
• src/screens/UserPortal/Posts/Posts.test.tsx (4 hunks)
• src/screens/Users/Users.test.tsx (1 hunks)

💤 Files with no reviewable changes (6)

• .github/workflows/pull-request.yml
• .idea/.gitignore
• .idea/inspectionProfiles/Project_Default.xml
• .idea/modules.xml
• .idea/talawa-admin.iml
• .idea/vcs.xml

✅ Files skipped from review due to trivial changes (1)

• .github/pull_request_template.md

🔇 Additional comments (9)

src/components/Pagination/Pagination.test.tsx (2)

60-61: Duplicate pattern: Consider using userEvent instead of fireEvent

Same issue as above - replacing userEvent with fireEvent goes against testing best practices and the PR's upgrade objective.

---

2-2: Verify the testing library usage across the codebase

Let's check if this pattern of replacing userEvent with fireEvent exists in other test files and understand the context better.

src/components/OrganizationScreen/OrganizationScreen.test.tsx (1)

84-86: Verify CSS module class names against component styles

The test assertions have been updated to check for compound CSS module class names. While the changes look correct, we should verify these match the actual component's CSS modules.

Let's verify the CSS module class names:

Also applies to: 93-93

✅ Verification successful

CSS module class names are correctly referenced in the test

The test assertions are using the correct CSS module class names. The verification shows that:

• .pageContainer, .expand, and .contract classes exist in the component's CSS module
• The classes are used in the correct context for drawer toggle functionality
• The CSS module hash suffixes in the test match the build-time generated class names

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the CSS module class names exist in the component's CSS file

# Check if the CSS module contains these specific class names
rg -l "_pageContainer_ccl5z_1|_expand_ccl5z_15|_contract_ccl5z_121" src/components/OrganizationScreen/OrganizationScreen.module.css

# Show the context of these class names if found
rg -A 2 -B 2 "(\.|#)(pageContainer|expand|contract)" src/components/OrganizationScreen/OrganizationScreen.module.css

Length of output: 948

package.json (1)

116-116: Verify testing library compatibility

The upgrade to @testing-library/user-event@^13.5.0 looks good as an intermediate step. However, let's verify compatibility with other testing libraries.

✅ Verification successful

Testing library dependencies are compatible

The upgrade to @testing-library/user-event@^13.5.0 is safe based on the compatibility analysis:

• React (^18.3.1) and React DOM (^18.3.1) versions exceed the minimum requirements
• The only peer dependency for user-event v13.5.0 is @testing-library/dom>=7.21.4
• The React Testing Library v16.0.1 requires @testing-library/dom^10.0.0, which satisfies user-event's requirement
• There are numerous test files using user-event, but the version upgrade from 12.8.3 to 13.5.0 maintains backward compatibility for most APIs

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check compatibility between testing library versions

# Get the compatibility matrix from npm for related packages
echo "Checking compatibility matrix for @testing-library packages..."
npm info '@testing-library/[email protected]' peerDependencies
npm info '@testing-library/[email protected]' peerDependencies
npm info '@testing-library/[email protected]' peerDependencies

# Check for any known breaking changes or issues
echo "Checking for known issues..."
npm view @testing-library/[email protected] bugs.url

Length of output: 677

---

Script:

#!/bin/bash
# Let's check the actual React and React DOM versions in package.json
echo "Checking React and React DOM versions..."
rg '"react":|"react-dom":' package.json

# Let's also check for @testing-library/dom version
echo -e "\nChecking @testing-library/dom version..."
rg '"@testing-library/dom":' package.json

# Let's verify if there are any failing tests that might be related
echo -e "\nChecking for test files using user-event..."
rg -l "@testing-library/user-event"

Length of output: 5986

src/screens/UserPortal/People/People.test.tsx (1)

191-193: LGTM! Good addition of initial state verification.

The new assertion properly verifies the search input's initial empty state before any user interaction, following testing best practices.

Let's verify compatibility with the upgraded @testing-library/user-event v13.5.0:

✅ Verification successful

After reviewing the test file content, I can generate the final response as we have sufficient information to verify the compatibility and correctness of the changes.

The initial state verification is correctly implemented and compatible with @testing-library/user-event v13.5.0

The test file shows proper usage of toHaveValue() matcher with @testing-library/user-event, and the assertion is correctly placed before any user interactions. The test follows the upgrade-compatible patterns:

• Uses standard screen.getByTestId() query
• Properly implements userEvent for subsequent interactions
• Maintains correct test structure with proper async/await handling

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for breaking changes in @testing-library/user-event v13.5.0 that might affect toHaveValue matcher

# Search for all toHaveValue assertions to ensure consistent usage
rg "toHaveValue" --type ts --type tsx

# Search for any existing issues or workarounds related to the upgrade
rg -B 2 -A 2 "@testing-library/user-event.*13\.5\.0" "package.json"

Length of output: 327

---

Script:

#!/bin/bash
# Let's try with correct file extensions and also check the test file content
rg "toHaveValue" -t tsx -t ts -t jsx -t js

# Let's also look at the specific test file content
cat src/screens/UserPortal/People/People.test.tsx

# Check for any user-event usage patterns
rg "userEvent" -t tsx -t ts -t jsx -t js -B 2 -A 2

Length of output: 6282

src/screens/UserPortal/Posts/Posts.test.tsx (3)

4-4: LGTM: Clean import statement update

The removal of unused waitFor import aligns with the new testing pattern using act.

---

290-290: LGTM: Proper async rendering handling with act

The addition of act wrapping around renderHomeScreen calls ensures proper handling of async rendering and effects, preventing "act" warnings and following React testing best practices.

Also applies to: 298-298, 310-310, 347-347

---

6-6: Verify @testing-library/user-event upgrade implementation

Since this PR upgrades @testing-library/user-event to v13.5.0, let's verify if all userEvent calls follow the new version's patterns.

✅ Verification successful

Based on the search results, I can see that all userEvent usage patterns in the codebase follow the v13 patterns, specifically:

1. Direct method calls like userEvent.type(), userEvent.click(), userEvent.clear() without setup/initialization
2. Proper usage of async/await with waitFor/wait helpers
3. Correct event method signatures (e.g. type with input element and string value)
4. No deprecated method usage

Let me verify the package.json to confirm the version:

---

All userEvent implementations are compatible with v13.5.0

The codebase correctly implements @testing-library/user-event v13.5.0 patterns:

• Uses direct method calls without setup/initialization
• Properly handles async operations with waitFor/wait
• Uses correct event method signatures
• No deprecated methods found

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for userEvent usage patterns that might need updates for v13
rg "userEvent\." -A 2 -B 2

Length of output: 129953

---

Script:

#!/bin/bash
# Check package.json for @testing-library/user-event version
rg '"@testing-library/user-event"' -A 1 -B 1 package.json

Length of output: 179

src/screens/Users/Users.test.tsx (1)

Line range hint 10-10: Verify compatibility with @testing-library/user-event v13.

Since we're upgrading from v12 to v13, let's verify that all userEvent methods used in this file are compatible with v13.

✅ Verification successful

No compatibility issues with @testing-library/user-event v13 upgrade

The methods used in the file (type, clear, and click) are core functionalities that remain stable in v13. The package.json shows we're already using version ^13.5.0, and these methods maintain the same API across versions.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential breaking changes in userEvent usage

# Search for all userEvent method calls
echo "Checking userEvent method usage:"
rg "userEvent\." -A 1

# Check package.json for the new version
echo -e "\nVerifying package version:"
rg '"@testing-library/user-event":\s*"13' package.json

Length of output: 105378

---

Script:

#!/bin/bash
# Let's verify the userEvent methods used in the file under review and check package.json for version info

# First, check the specific file for userEvent usage
echo "Checking userEvent usage in Users.test.tsx:"
rg "userEvent\." src/screens/Users/Users.test.tsx -A 1

# Then check package.json for both old and new versions
echo -e "\nChecking package.json for user-event versions:"
rg '"@testing-library/user-event":\s*"(12|13)' package.json

Length of output: 1097

---

Script:

#!/bin/bash
# Let's check package.json directly to see the version
echo "Checking full package.json content for user-event:"
cat package.json | grep -A 1 -B 1 "user-event"

# Also check for any breaking changes in the methods used
echo -e "\nChecking methods used in the file:"
rg "userEvent\.(type|clear|click)" src/screens/Users/Users.test.tsx --no-line-number

Length of output: 1049

[coderabbitai]

🛠️ Refactor suggestion

Consider using userEvent instead of fireEvent

The change from userEvent to fireEvent seems to contradict the PR's objective of upgrading @testing-library/user-event. userEvent is recommended over fireEvent as it more accurately simulates real user interactions by:

• Firing multiple events that occur in a real browser
• Better replicating actual user behavior
• Providing better accessibility testing

Consider this implementation instead:

- fireEvent.click(screen.getByTestId(/nextPage/i));
- fireEvent.click(screen.getByTestId(/previousPage/i));
+ const user = userEvent.setup()
+ await user.click(screen.getByTestId(/nextPage/i));
+ await user.click(screen.getByTestId(/previousPage/i));

Note: With @testing-library/user-event v13+, we need to use the new setup() API and await the interactions.

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

🛠️ Refactor suggestion

Improve search not found test case.

The test case can be improved by:

1. Removing unnecessary act wrapper around userEvent
2. Adding assertions to verify the "not found" state

-    await act(async () => {
-      userEvent.type(screen.getByTestId(/searchByName/i), search);
-    });
+    const user = userEvent.setup();
+    await user.type(screen.getByTestId(/searchByName/i), search);
+    expect(screen.getByTestId(/searchByName/i)).toHaveValue('hello');
+    expect(screen.getByText(/No Membership Requests Found/i)).toBeInTheDocument();

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

🛠️ Refactor suggestion

Simplify async assertions to avoid redundant waiting

The current implementation has redundant async operations that could mask timing issues:

1. The waitFor callback doesn't need to be async
2. Using await findByText inside waitFor is redundant as both functions wait for elements

Consider this more efficient approach:

-    await waitFor(async () => {
+    await waitFor(() => {
       expect(screen.getByTestId('searchPledges')).toBeInTheDocument();
-      expect(await screen.findByText('Harve Lance')).toBeInTheDocument();
-      expect(await screen.findByText('John Doe')).toBeInTheDocument();
+      expect(screen.getByText('Harve Lance')).toBeInTheDocument();
+      expect(screen.getByText('John Doe')).toBeInTheDocument();
     });

Alternatively, if you need to wait for elements to appear:

-    await waitFor(async () => {
-      expect(screen.getByTestId('searchPledges')).toBeInTheDocument();
-      expect(await screen.findByText('Harve Lance')).toBeInTheDocument();
-      expect(await screen.findByText('John Doe')).toBeInTheDocument();
-    });
+    expect(screen.getByTestId('searchPledges')).toBeInTheDocument();
+    await screen.findByText('Harve Lance');
+    await screen.findByText('John Doe');

Committable suggestion skipped: line range outside the PR's diff.

[palisadoes]

This PR has too many submitted files.

Please ensure the following:

1. Fetch the latest upstream/develop files
2. Make your PR modifications based on the local copy of this develop-postgres branch
3. Submit your PRs against our develop-postgres branch.
4. Your source branch in your local repository must not be the same as the target branch

Closing