feat: Add unit tests for MetricsCard component#1880
Conversation
- Covered rendering with valid props and edge cases
- Tested fallback for empty project name ("No name")
- Verified conditional styling based on score ranges
- Checked correct link generation using projectKey
|
Warning Rate limit exceeded@kasya has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 7 minutes and 32 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)
Summary by CodeRabbit
WalkthroughA new unit test suite for the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes detected. Suggested reviewers
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
frontend/__tests__/unit/components/MetricsCard.test.tsx (1)
31-47: Thorough score styling tests with good range coverage.The tests effectively cover all three score ranges. Consider adding tests for boundary values (75 and 50) to ensure the conditional logic handles edge cases correctly.
+ it('uses green styling for score exactly at 75 boundary', () => { + render(<MetricsCard metric={{ ...baseMetric, score: 75 }} />) + const score = screen.getByText('75') + expect(score).toHaveClass('text-green-900') + }) + + it('uses orange styling for score exactly at 50 boundary', () => { + render(<MetricsCard metric={{ ...baseMetric, score: 50 }} />) + const score = screen.getByText('50') + expect(score).toHaveClass('text-orange-900') + })
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
frontend/__tests__/unit/components/MetricsCard.test.tsx(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: Rajgupta36
PR: OWASP/Nest#1717
File: frontend/__tests__/unit/pages/createProgram.test.tsx:70-86
Timestamp: 2025-07-12T17:36:57.255Z
Learning: When testing React page components that use mocked form components, validation logic should be tested at the form component level, not the page level. Page-level tests should focus on authentication, role checking, submission handling, and navigation logic.
Learnt from: ahmedxgouda
PR: OWASP/Nest#1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a length check before rendering HealthMetrics: `healthMetricsData.length > 0`. This ensures that when HealthMetrics is rendered, the data array has at least one element, making accessing data[0] safe within the HealthMetrics component.
Learnt from: ahmedxgouda
PR: OWASP/Nest#1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a safety check that ensures HealthMetrics component is only rendered when healthMetricsData exists and has at least one element: `healthMetricsData && healthMetricsData.length > 0`. This makes accessing data[0] safe within the HealthMetrics component.
frontend/__tests__/unit/components/MetricsCard.test.tsx (3)
Learnt from: ahmedxgouda
PR: #1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a length check before rendering HealthMetrics: healthMetricsData.length > 0. This ensures that when HealthMetrics is rendered, the data array has at least one element, making accessing data[0] safe within the HealthMetrics component.
Learnt from: ahmedxgouda
PR: #1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a safety check that ensures HealthMetrics component is only rendered when healthMetricsData exists and has at least one element: healthMetricsData && healthMetricsData.length > 0. This makes accessing data[0] safe within the HealthMetrics component.
Learnt from: Rajgupta36
PR: #1717
File: frontend/tests/unit/pages/createProgram.test.tsx:70-86
Timestamp: 2025-07-12T17:36:57.255Z
Learning: When testing React page components that use mocked form components, validation logic should be tested at the form component level, not the page level. Page-level tests should focus on authentication, role checking, submission handling, and navigation logic.
🔇 Additional comments (6)
frontend/__tests__/unit/components/MetricsCard.test.tsx (6)
1-4: LGTM! Clean and appropriate imports.The imports include all necessary testing utilities and the component under test.
5-14: Well-structured test data setup.The baseMetric object provides a solid foundation for all test cases with realistic data values.
16-24: Comprehensive basic rendering test.Good coverage of all key elements including proper date formatting verification.
26-29: Good edge case coverage for empty project name.Properly tests the fallback behavior when projectName is empty.
49-53: Effective link generation test.Properly verifies that the correct URL is generated based on the projectKey prop.
55-75: Excellent prop updates test.Thoroughly tests component reactivity to prop changes, including both display content and link URL updates.
|
@sriyavinaya hi! Do you plan to address requested changes soon? If not we'll give this issue to someone else. |
|
kasya
left a comment
There was a problem hiding this comment.
@sriyavinaya thanks for addressing this. There was one failing test still + it seems that you did not run make check before your commit.
I pushed changes to fix both and will merge this in 👌🏼
Thank you for pointing that out, and I’m really sorry for the inconvenience caused. I did attempt to run make check, but unfortunately it kept failing due to storage limitations on my laptop. I went ahead with the commit as I didn’t want to block progress, but I understand the importance of ensuring all checks pass beforehand. I’ll make sure to resolve the local issue and be more thorough in future contributions. Thanks again for your support and for merging the fix |
* test: add unit tests for MetricsCard component
- Covered rendering with valid props and edge cases
- Tested fallback for empty project name ("No name")
- Verified conditional styling based on score ranges
- Checked correct link generation using projectKey
* test: add boundary tests for score = 75 and 50 in MetricsCard
* test: added properties from HealthMetricsProps
* test: added properties from HealthMetricsProps
* Fix tests and make check issues
---------
Co-authored-by: Kate Golovanova <kate@kgthreads.com>




Resolves #1844
Proposed change
Checklist
make check-testlocally; all checks and tests passed.