Refactor: src/screens/UserPortal/Posts from Jest to Vitest #2683
Conversation
|
Warning Rate limit exceeded@Niyatijain-9 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 9 minutes and 14 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThe pull request focuses on refactoring the Changes
Assessment against linked issues
Possibly related issues
Suggested labels
Suggested reviewers
Poem
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
Documentation and Community
|
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
src/screens/UserPortal/Posts/Posts.test.tsx (3)
19-26: Clean up empty lines in imports sectionThe migration to Vitest looks good, but there's an unnecessary empty line between imports and the mock setup.
import { DELETE_POST_MUTATION } from 'GraphQl/Mutations/mutations'; import { vi } from 'vitest'; - vi.mock('react-toastify', () => ({🧰 Tools
🪛 eslint
[error] 21-22: Delete
⏎(prettier/prettier)
237-246: Consider using a more concise matchMedia mock implementationWhile the current implementation works, it could be simplified by using object method shorthand notation.
value: vi.fn().mockImplementation((query) => ({ matches: false, media: query, onchange: null, - addListener: vi.fn(), - removeListener: vi.fn(), - addEventListener: vi.fn(), - removeEventListener: vi.fn(), - dispatchEvent: vi.fn(), + addListener: () => {}, + removeListener: () => {}, + addEventListener: () => {}, + removeEventListener: () => {}, + dispatchEvent: () => {}, })),
257-266: Enhance pinned post test robustnessThe current test only verifies the presence of a pinned post. Consider adding assertions for:
- The pinned status indicator
- The correct ordering when multiple posts exist
test('Check if pinned post is displayed at the top', async () => { renderHomeScreen(); await wait(); const pinnedPost = await screen.findByText('post one'); const postsContainer = screen.getByTestId('postsContainer'); + const pinnedIndicator = within(pinnedPost).getByTestId('pinned-indicator'); expect( within(postsContainer).getAllByText('post one')[0], ).toBeInTheDocument(); + expect(pinnedIndicator).toBeInTheDocument(); expect(postsContainer.firstChild).toContainElement(pinnedPost); + const allPosts = within(postsContainer).getAllByTestId(/^post-/); + expect(allPosts[0]).toBe(pinnedPost); });
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/screens/UserPortal/Posts/Posts.test.tsx(3 hunks)
🧰 Additional context used
🪛 eslint
src/screens/UserPortal/Posts/Posts.test.tsx
[error] 21-22: Delete ⏎
(prettier/prettier)
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
src/screens/UserPortal/Posts/Posts.test.tsx (1)
Line range hint
29-186: Add error and loading state mocksThe current mocks only cover successful scenarios. Consider adding mocks for:
- API errors
- Loading states
- Empty data states
Add these mock configurations:
const ERROR_MOCKS = [ { request: { query: ORGANIZATION_POST_LIST, variables: { id: 'orgId', first: 10 }, }, error: new Error('Failed to fetch posts'), }, ]; const EMPTY_MOCKS = [ { request: { query: ORGANIZATION_POST_LIST, variables: { id: 'orgId', first: 10 }, }, result: { data: { organizations: [{ posts: { edges: [], pageInfo: { hasNextPage: false, hasPreviousPage: false, }, totalCount: 0, }, }], }, }, }, ];
♻️ Duplicate comments (3)
src/screens/UserPortal/Posts/Posts.test.tsx (3)
267-274:⚠️ Potential issueAdd proper state update verification for like functionality
The current test doesn't properly wait for state updates after clicking the like button.
test('Check if a post can be liked', async () => { renderHomeScreen(); await wait(); const likeBtn = await screen.findByTestId( 'likeBtn-6411e54835d7ba2344a78e29', ); + expect(likeBtn).toHaveTextContent('2'); userEvent.click(likeBtn); - expect(likeBtn).toHaveTextContent('3'); + await waitFor(() => { + expect(likeBtn).toHaveTextContent('3'); + expect(likeBtn).not.toBeDisabled(); + }); });
333-341: 🛠️ Refactor suggestionEnhance pagination test coverage
The current pagination test is too basic. It should verify the content and state of both pages.
test('Check if pagination works', async () => { renderHomeScreen(); await wait(); + // Verify initial state + const firstPagePosts = screen.getAllByTestId(/^post-/); + expect(firstPagePosts).toHaveLength(2); + expect(screen.getByText('post one')).toBeInTheDocument(); + const nextPageBtn = await screen.findByTestId('nextPageBtn'); expect(nextPageBtn).toBeInTheDocument(); + userEvent.click(nextPageBtn); + await waitFor(() => { expect(screen.queryByText('post one')).not.toBeInTheDocument(); + const secondPagePosts = screen.getAllByTestId(/^post-/); + expect(secondPagePosts).not.toEqual(firstPagePosts); + expect(nextPageBtn).toBeDisabled(); }); + + // Test previous page navigation + const prevPageBtn = screen.getByTestId('prevPageBtn'); + userEvent.click(prevPageBtn); + + await waitFor(() => { + expect(screen.getByText('post one')).toBeInTheDocument(); + expect(prevPageBtn).toBeDisabled(); + }); });
248-254:⚠️ Potential issueAdd missing test coverage for loading and error states
The test suite still lacks coverage for important edge cases that were highlighted in previous reviews.
Add these essential test cases:
- Loading states while data is being fetched
- Error handling when API calls fail
- Empty states when no posts are available
Example implementation:
test('Should show loading state', async () => { renderHomeScreen(); expect(screen.getByTestId('loading-spinner')).toBeInTheDocument(); }); test('Should handle API errors gracefully', async () => { const errorLink = new StaticMockLink(ERROR_MOCKS, true); render( <MockedProvider link={errorLink}> <Home /> </MockedProvider> ); await waitFor(() => { expect(screen.getByText('Error loading posts')).toBeInTheDocument(); }); }); test('Should display empty state message', async () => { const emptyLink = new StaticMockLink(EMPTY_MOCKS, true); render( <MockedProvider link={emptyLink}> <Home /> </MockedProvider> ); await waitFor(() => { expect(screen.getByText('No posts available')).toBeInTheDocument(); }); });
🧹 Nitpick comments (2)
src/screens/UserPortal/Posts/Posts.test.tsx (2)
21-27: Enhance mock implementation with error scenariosThe current mock implementation for
react-toastifyis basic. Consider enhancing it to verify toast calls and their arguments.vi.mock('react-toastify', () => ({ toast: { - error: vi.fn(), - info: vi.fn(), - success: vi.fn(), + error: vi.fn().mockImplementation((msg) => { + console.log('Toast error:', msg); + return msg; + }), + info: vi.fn().mockImplementation((msg) => { + console.log('Toast info:', msg); + return msg; + }), + success: vi.fn().mockImplementation((msg) => { + console.log('Toast success:', msg); + return msg; + }), }, }));
236-244: Consider moving window.matchMedia mock to test utilsThe window.matchMedia mock could be reused across different test files.
Consider moving this to a shared test utils file, e.g.,
src/utils/testUtils.ts:// src/utils/testUtils.ts export const setupMatchMediaMock = (): void => { Object.defineProperty(window, 'matchMedia', { writable: true, value: vi.fn().mockImplementation((query) => ({ matches: false, media: query, onchange: null, addListener: vi.fn(), removeListener: vi.fn(), addEventListener: vi.fn(), removeEventListener: vi.fn(), dispatchEvent: vi.fn(), })), }); };
|
We have a policy of unassigning contributors who close PRs without getting validation from our reviewer team. This is because:
Please be considerate of our volunteers' limited time and our desire to improve our code base. This policy is stated as a pinned post in all our Talawa repositories. Our YouTube videos explain why this practice is not acceptable to our Community. In most cases you don’t have to close the PR to trigger the GitHub workflow to run again. Making a new commit and pushing it to your GitHub account will normally be sufficient. Unfortunately, if this continues we will have to close the offending PR and unassign you from the issue. |
|
Hello, I am extremely sorry for this.
Hello, I am extremely sorry for this. I had raised the pr #2681 earlier but as I mentioned in it that I had only made changes it one file but in the file changed column it unexpectedly showed49 files changed. I tried deleting the extra files but that too didn't help. Therefore I had to make another PR #2683. I am extremely sorry for the inconvienience caused. I will take care of it from the future. Kindly assign me as I have solved the issue to some extent and would really like to work on it. |
That should solve the issue with the excessive number of files |
What kind of change does this PR introduce?
It is a refactor of changing the test case migration of jest to vitest.
Issue Number:
Fixes #2578
Did you add tests for your changes?
Yes
Snapshots/Videos:
If relevant, did you update the documentation?
Summary
This code is tested with vitest and all the tests are run and passed.
Does this PR introduce a breaking change?
No, does not affect other code workflow
Other information
Have you read the contributing guide?
Yes
Summary by CodeRabbit