Skip to content

Add unit tests for request manager actions#7166

Merged
jpople merged 11 commits intomainfrom
ENG-1626-Add-unit-test-for-request-actions
Feb 10, 2026
Merged

Add unit tests for request manager actions#7166
jpople merged 11 commits intomainfrom
ENG-1626-Add-unit-test-for-request-actions

Conversation

@lucanovera
Copy link
Copy Markdown
Contributor

@lucanovera lucanovera commented Dec 19, 2025

Ticket ENG-1626

Description Of Changes

Adds unit tests for the RequestTableActions.tsx component. Tests both which action is shown as well as the interactions with each action.

Test Suites (21 tests)

  • Action Visibility (13 tests): Validates correct button visibility for all privacy request statuses (pending, duplicate, identity_unverified, requires_input, approved, denied, in_processing, complete, paused, error, canceled, awaiting_email_send, requires_manual_finalization)
  • Loading States (2 tests): Verifies buttons are disabled and show loading indicators when mutations are in progress
  • Complete User Flows (4 tests): End-to-end tests for approve, deny, delete, and finalize actions (button click → modal open → confirm → mutation called → modal close)
  • Keyboard Navigation (2 tests): Ensures buttons are accessible via keyboard (tab navigation and Enter key activation)

Key Features Tested

  • Status-based conditional rendering of action buttons
  • Modal open/close behavior for all actions
  • Loading state handling across all buttons
  • Full user interaction flows with proper state management
  • Keyboard accessibility compliance

Code Changes

  • Added RequestTableActions.test.tsx

Steps to Confirm

  1. CI passes

Pre-Merge Checklist

  • Issue requirements met
  • All CI pipelines succeeded
  • CHANGELOG.md updated
    • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
    • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
    • Updates unreleased work already in Changelog, no new entry necessary
  • UX feedback:
    • All UX related changes have been reviewed by a designer
    • No UX review needed
  • Followup issues:
    • Followup issues created
    • No followup issues
  • Database migrations:
    • Ensure that your downrev is up to date with the latest revision on main
    • Ensure that your downgrade() migration is correct and works
      • If a downgrade migration is not possible for this change, please call this out in the PR description!
    • No migrations
  • Documentation:
    • Documentation complete, PR opened in fidesdocs
    • Documentation issue created in fidesdocs
    • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
    • No documentation updates required

@vercel
Copy link
Copy Markdown
Contributor

vercel bot commented Dec 19, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
fides-plus-nightly Ignored Ignored Preview Feb 9, 2026 10:47pm
fides-privacy-center Ignored Ignored Feb 9, 2026 10:47pm

Request Review

@lucanovera lucanovera marked this pull request as ready for review December 19, 2025 07:22
@lucanovera lucanovera requested a review from a team as a code owner December 19, 2025 07:22
@lucanovera lucanovera requested review from speaker-ender and removed request for a team December 19, 2025 07:22
Copy link
Copy Markdown
Contributor

@speaker-ender speaker-ender left a comment

Choose a reason for hiding this comment

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

I have a few questions and concerns about what we are testing in this file.
If we want to make sure we have basic coverage I can approve but I worry about the long term efficacy of some of these tests.

Comment on lines +181 to +185
/**
* Action visibility matrix for all privacy request statuses.
* This table drives the parameterized tests below.
*/
const actionVisibilityByStatus = [
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this is good. Having a hard coded list of possible states for testing

Comment on lines +293 to +296
expectButtonVisibility(buttons.approve, approve);
expectButtonVisibility(buttons.deny, deny);
expectButtonVisibility(buttons.finalize, finalize);
expectButtonVisibility(buttons.delete, deleteBtn);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there a reason the logic/components being tested here were not extracted?
Having to render the parent component to test this logic seems excessive.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Good suggestion-- I moved the logic for button visibility into a separate helper function and we now test that directly without rendering the component.

Comment on lines +368 to +377
const modal = screen.getByTestId("confirmation-modal");
expect(modal).toBeInTheDocument();

const confirmBtn = screen.getByTestId("confirmation-modal-confirm");
await user.click(confirmBtn);

expect(mockHandleDeleteRequest).toHaveBeenCalledTimes(1);
expect(
screen.queryByTestId("confirmation-modal"),
).not.toBeInTheDocument();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm struggling to understand what code is being tested here that isn't just being mocked above.
The modal is a mock, the confirm button is being mocked, the onClick action is being mocked, and the request hook and data is being mocked.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah, I've just gone ahead and removed these-- if there's something here that should be getting tested with real components etc. that I should add back in let me know.

render(<RequestTableActions subjectRequest={baseRequest} />);

const approveBtn = screen.getByTestId("privacy-request-approve-btn");
expect(approveBtn).toHaveAttribute("aria-busy", "true");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why are we testing a mocked attribute?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yep, went ahead and removed this one too.

Comment on lines +21 to +23
get isLoading() {
return mockIsLoading;
},
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is it not possible to mock this via a jest mock fn?
Using a mutable variable for this seems error prone.

@jpople jpople requested a review from speaker-ender February 10, 2026 16:04
@jpople jpople added this pull request to the merge queue Feb 10, 2026
Merged via the queue into main with commit a614a66 Feb 10, 2026
46 checks passed
@jpople jpople deleted the ENG-1626-Add-unit-test-for-request-actions branch February 10, 2026 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants