Test: Verification Request Lifecycle Coverage with Cypress

[LuizFNJ]

Description

This Pull Request consolidates a series of improvements for the Verification Request flow, ranging from UX refinements and form validation logic to infrastructure for automated testing and full E2E coverage.

Key Changes:

• Dynamic Drawer Navigation: Refactored the "Cancel" button behavior within drawers (Verification Request, Badges, and Namespaces). It now closes the drawer component instead of triggering a browser history back action, preventing unintended navigation.
• Form Validation & Performance Optimization: Refactored the Source List component to pass strictly sanitized string (href) arrays as default values, resolving a validation bug that previously blocked field updates. The component now utilizes a debounced onChange handler to ensure state updates only trigger after the user finishes typing, paired with useCallback for list changes to maintain referential integrity and prevent unnecessary child re-renders.
• Custom Impact Areas: Enabled the creation of new Impact Areas directly from the autocomplete field, aligning its behavior with the Topics field. Users are no longer restricted to predefined options.
• Testing Infrastructure: Added necessary data-cy selectors across the Verification Request forms to enable robust automated testing.

Automated Scenarios Covered:

1. Full Creation Flow: Validates the creation of a verification request using all optional and mandatory fields.
2. Full Update Flow: Ensures an existing request can be updated by adding additional sources and modifying the publication date.
3. Mandatory Field Validation: Confirms the system prevents submission when "Content" or "Publication Date" are missing.
4. Minimalist Lifecycle:
   • Creation: Verifies request creation using only the minimum mandatory information.
   • Supplementing: Validates adding the first source to a previously minimalist request during a subsequent edit.
5. Topic Management: Covers adding new topics (including custom entries not in autocomplete) and removing them from an existing request.
6. Cancel Action Integrity: Ensures that clicking the "Cancel" button correctly discards unsaved changes and preserves the original data state.

Related Ticket #2255 #2212

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Existing feature enhancement (non-breaking change which modifies existing functionality)

Manual Verification:

• Open the Verification Request form:
  • If rendered inside a Drawer: Verify that clicking 'Cancel' closes the component without changing the URL.
  • If rendered as a Standalone Page: Verify that clicking 'Cancel' triggers a browser back navigation to the previous route.
• Try to edit a request by only changing the date (without adding sources) to ensure the validation no longer blocks the submission.
• Type a non-existent Impact Area and press enter to ensure it is accepted.

Developer Checklist

General

• Code is appropriately commented, particularly in hard-to-understand areas
• Repository documentation has been updated (Readme.md) with additional steps required for a local environment setup.
• No console.log or related logging is added.
• No code is repeated/duplicated in violation of DRY. The exception to this is for new (MVP/Prototype) functionality where the abstraction layer may not be clear (comments should be added to explain the violation of DRY in these scenarios).
• Documented with TSDoc all library and controller new functions

Frontend Changes

• No new styling is added through CSS files (Unless it's a bugfix/hotfix)
• All types are added correctly

Backend Changes

• All endpoints are appropriately secured with Middleware authentication
• All new endpoints have a interface schema defined

Tests

• All existing unit and end to end tests pass across all services
• Unit and end to end tests have been added to ensure backend APIs behave as expected

Test IDs

• Include the test ID when adding new tasks or components.
• Check that test IDs are present in the modified components.

Merge Request Review Checklist

• An issue is linked to this PR and these changes meet the requirements outlined in the linked issue(s)
• High risk and core workflows have been tested and verified in a local environment.
• Enhancements or opportunities to improve performance, stability, security or code readability have been noted and documented in Project do Github issues if not being addressed.
• Any dependent changes have been merged and published in downstream modules
• Changes to multiple services can be deployed in parallel and independently. If not, changes should be broken out into separate merge requests and deployed in order.