Skip to content

feat: Add unit tests for MetricsCard component#1880

Merged
kasya merged 10 commits intoOWASP:mainfrom
sriyavinaya:feat/add-metricscard-unit-test
Aug 3, 2025
Merged

feat: Add unit tests for MetricsCard component#1880
kasya merged 10 commits intoOWASP:mainfrom
sriyavinaya:feat/add-metricscard-unit-test

Conversation

@sriyavinaya
Copy link
Contributor

Resolves #1844

Proposed change

  • 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
  • Simulated prop updates using rerender to match dynamic behavior

Checklist

  • I've read and followed the contributing guidelines.
  • I've run make check-test locally; all checks and tests passed.

- 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
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jul 27, 2025

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

📥 Commits

Reviewing files that changed from the base of the PR and between d95916a and 5a31a0a.

📒 Files selected for processing (1)
  • frontend/__tests__/unit/components/MetricsCard.test.tsx (1 hunks)

Summary by CodeRabbit

  • Tests
    • Added comprehensive unit tests for the MetricsCard component, covering rendering, conditional styling, display of project details, and dynamic updates based on prop changes.

Walkthrough

A new unit test suite for the MetricsCard React component was introduced. The tests cover rendering with various props, conditional display logic, score-based styling, link generation, and component updates when props change.

Changes

Files Change Summary
MetricsCard tests
frontend/__tests__/unit/components/MetricsCard.test.tsx
Added a comprehensive test suite for the MetricsCard component, covering rendering, conditional styling, prop changes, and link behavior.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

Assessment against linked issues

Objective Addressed Explanation
Renders successfully with minimal required props (from #1844)
Conditional rendering logic (from #1844)
Prop-based behavior – different props affect output (from #1844)
Event handling – simulate user actions and verify callbacks (from #1844) No event handling tests present.
State changes / internal logic (from #1844) Tested via prop updates causing re-render.
Default values and fallbacks (from #1844) Tested empty project name fallback.
Text and content rendering (from #1844)
Handles edge cases and invalid inputs (from #1844) Tested boundary score values and empty project name.
Accessibility roles and labels (from #1844) No explicit accessibility tests found.
DOM structure / classNames / styles (from #1844) Tested conditional score color classes.

Assessment against linked issues: Out-of-scope changes

No out-of-scope changes detected.

Suggested reviewers

  • kasya
  • arkid15r
✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share
🪧 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.
    • Explain this complex logic.
    • 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 explain this code block.
    • @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 explain its main purpose.
    • @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.

Support

Need 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)

  • @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 generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 3d0153f and de398ea.

📒 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.

Copy link
Collaborator

@kasya kasya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please run make check locally and push updates files. It's required for opening a PR in OWASP Nest.

I also ran your tests locally and got these errors. Please address these too before requesting a review:
Screenshot 2025-07-27 at 10 20 55 AM

@kasya
Copy link
Collaborator

kasya commented Aug 2, 2025

@sriyavinaya hi! Do you plan to address requested changes soon? If not we'll give this issue to someone else.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Aug 3, 2025

Copy link
Collaborator

@kasya kasya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 👌🏼

@kasya kasya enabled auto-merge August 3, 2025 02:37
@kasya kasya added this pull request to the merge queue Aug 3, 2025
Merged via the queue into OWASP:main with commit c0a27de Aug 3, 2025
24 checks passed
@sriyavinaya
Copy link
Contributor Author

@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

trucodd pushed a commit to trucodd/Nest that referenced this pull request Aug 5, 2025
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add tests for <MetricsCard> component

2 participants