-
-
Notifications
You must be signed in to change notification settings - Fork 196
test: add unit tests for GeneralCompliantComponent #2018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Summary by CodeRabbit
No user-facing features or behavior changes were introduced in this release. WalkthroughAdded a new unit test file for GeneralCompliantComponent and updated frontend devDependencies to include @testing-library/dom. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changes
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ 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. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (7)
frontend/package.json (1)
73-73
: Avoid the extra dependency by re-exported utilitiesYou don't need a direct dependency on @testing-library/dom if you import screen from @testing-library/react. It re-exports DOM utilities. Simplify the tree and avoid version skew by removing this dep once imports are updated in the test.
- "@testing-library/dom": "^10.4.1",
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx (6)
9-13
: Tighten test prop types; avoid anyPrefer the concrete icon type to catch mismatches at compile time.
+import type { IconDefinition } from '@fortawesome/fontawesome-svg-core'; @@ type GeneralCompliantComponentProps = { compliant: boolean; - icon: any; + icon: IconDefinition; title: string; };
39-42
: Minor duplication with the first render testThis largely overlaps “renders successfully with minimal required props.” Consider merging or making the assertion more specific (e.g., verify structure/order around icon + title).
44-48
: Tooltip assertion is brittle without interactionAsserting raw text risks false positives if the title is also visible inline. Prefer an accessible query (e.g., role="tooltip") and simulate hover if the tooltip is conditional.
Example approach:
- If using a real tooltip: use user-event to hover the trigger, then assert by role.
- If using title/aria-label: assert via getByTitle or toHaveAttribute.
-import { faCertificate } from '@fortawesome/free-solid-svg-icons'; +import { faCertificate } from '@fortawesome/free-solid-svg-icons'; +import userEvent from '@testing-library/user-event'; @@ - it('renders tooltip with the title', () => { - const { getByText } = render(<GeneralCompliantComponent {...baseProps} title="Tooltip Title" />); - // Tooltip content is rendered, but may require hover simulation in real DOM - expect(getByText('Tooltip Title')).toBeInTheDocument(); - }); + it('shows tooltip content on hover', async () => { + render(<GeneralCompliantComponent {...baseProps} title="Tooltip Title" />); + const trigger = screen.getByText('Tooltip Title'); // Or a more specific trigger + await userEvent.hover(trigger); + expect(screen.getByRole('tooltip')).toHaveTextContent('Tooltip Title'); + });If the component does not render a role="tooltip", adapt to its actual a11y contract (e.g., getByTitle).
50-53
: Empty title test is too weakAsserting that container exists doesn't validate behavior. Check for expected fallback/absence instead (e.g., no visible title, aria-label fallback, or no crash with console error suppression if applicable).
64-68
: Custom icon test should verify the override, not just presence of any SVGUse a different icon and assert by a stable attribute (FontAwesome sets data-icon). This ensures the passed icon is actually used.
-import { faCertificate } from '@fortawesome/free-solid-svg-icons'; +import { faCertificate, faXmark } from '@fortawesome/free-solid-svg-icons'; @@ - it('renders with custom icon', () => { - const customIcon = faCertificate; // Replace with another icon if needed - const { container } = render(<GeneralCompliantComponent {...baseProps} icon={customIcon} />); - expect(container.querySelector('svg')).toBeInTheDocument(); - }); + it('renders with custom icon', () => { + const customIcon = faXmark; + const { container } = render(<GeneralCompliantComponent {...baseProps} icon={customIcon} />); + expect(container.querySelector('svg[data-icon="xmark"]')).toBeInTheDocument(); + });If not using FontAwesome’s IconDefinition, assert with whatever stable selector the component renders.
4-4
: Optional: move jest-dom setup to a global test setupImporting jest-dom per test file is repetitive. Consider moving to a setup file (e.g., setupTests.ts) via Jest’s setupFilesAfterEnv.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx
(1 hunks)frontend/package.json
(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#1714
File: frontend/src/components/ProjectTypeDashboardCard.tsx:8-12
Timestamp: 2025-07-08T17:07:50.988Z
Learning: In the OWASP/Nest project, union types for component props are not necessary when they would require creating separate type definitions. The project prefers inline prop type definitions even for props with specific string values, maintaining consistency with the single-use component prop pattern.
Learnt from: codic-yeeshu
PR: OWASP/Nest#1444
File: frontend/src/components/NavDropDown.tsx:0-0
Timestamp: 2025-04-30T13:41:20.846Z
Learning: Use React's useId() hook rather than manually generating random strings when creating accessibility identifiers for UI components. This creates stable, unique IDs without causing hydration mismatches.
📚 Learning: 2025-07-12T17:36:57.255Z
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.
Applied to files:
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx
Outdated
Show resolved
Hide resolved
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx
Outdated
Show resolved
Hide resolved
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx
Outdated
Show resolved
Hide resolved
frontend/__tests__/unit/components/GeneralCompliantComponent.test.tsx
Outdated
Show resolved
Hide resolved
Hi @arkid15r, I’ve finished the changes for this PR and all available checks have passed. Please review when you have time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addresskrish Do you plan to address requested changes? |
Hi @kasya , yes, I'm working on the requested changes and will update the PR soon. |
// Add more tests as needed for event handling, state, etc. | ||
}); | ||
|
||
// ...existing code... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addresskrish We totally support using AI for tests generation, but at least check what it generates and clean the code up before committing changes.
Also the tests fail right now in many cases. Please run make test-frontend-unit
locally and address all issues
render(<GeneralCompliantComponent {...baseProps} />); | ||
const iconElement = screen.getByText(baseProps.title); // Asserts the title text is visible | ||
expect(iconElement).toBeInTheDocument(); | ||
// Or, if the icon has a specific role, you can check for that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also should be removed
frontend/package.json
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert this too - we don't need this new package
|
Proposed change
Resolves #1835
Added comprehensive unit tests for
GeneralCompliantComponent
to improve coverage and ensure consistent behavior across different props and edge cases.Changes include:
compliant=true
andcompliant=false
Checklist
make check-test
locally; all checks and tests passed.