Tests for resources

[Hubert-Szczepanski-SAP]

What this PR does / why we need it:

Why Edit functionality is not fully tested
Edit Resource tests are intentionally limited to basic initialization checks.

Multiple layers - The edit flow involves: openInAside, YamlSidePanel, YamlViewer, Monaco Editor, and onApply callback. Each layer requires complex setup and mocking.

Splitter Context complexity - Edit opens resources in a side panel managed by SplitterContext. This context cannot be easily mocked in Cypress component.

YAML editor (Monaco Editor) is a also complex to be mocked.

We verify the basics work, we should cover it in E2E

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

[andreaskienle]

A few remarks down below.

About the splitter: Have you tried wrapping the component in <SplitterLayout> in the mount function?

    cy.mount(
      <MemoryRouter>
        <SplitterProvider>
          <SplitterLayout>
            …
          </SplitterLayout>
        </SplitterProvider>
      </MemoryRouter>,

This way you can maybe open the YAML file in the aside panel and test the flow there.

If this is not possible, can we at least test the useHandleResourcePatch hook?

[andreaskienle]

Can we use data-testid? This is pretty much standard convention

[andreaskienle]

Any reason for switching to cy.intercept instead of stubbing the hook? By intercepting we couple the component test directly to the HTTP requrst. When we switch to GraphQL later, we will have to rewrite all these tests. By stubbing the hook, ideally, nothing will change for the using component.

[andreaskienle]

Are all these wait calls really necessary? When we add more tests, this will not scale very well. cy.get automatically waits and retries a little bit until the condition is true.

There is a section in the cypress documentation about this: https://docs.cypress.io/app/core-concepts/best-practices#Unnecessary-Waiting

Please check if this is needed.

[Copilot]

Pull Request Overview

This PR adds test coverage for the ManagedResources component by introducing dependency injection for hooks and creating comprehensive Cypress component tests. The changes enable easier testing of delete and edit operations by allowing mock implementations of hooks to be passed as props.

• Refactored ManagedResources component to accept optional hook overrides via props
• Added comprehensive Cypress component tests for delete and force delete operations
• Enhanced ActionsMenu component with test identifiers and removed unused parameter

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/components/ControlPlane/ManagedResources.tsx	Added dependency injection pattern for useApiResourceMutation and useHandleResourcePatch hooks to enable testing
src/components/ControlPlane/ManagedResources.cy.tsx	Added comprehensive Cypress component tests covering delete, force delete, validation, and edit functionality
src/components/ControlPlane/ActionsMenu.tsx	Added data-testid attribute and data-component-name for test identification, removed unused buttonIcon parameter from function signature

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The buttonIcon parameter is still defined in the ActionsMenuProps type (line 17) but has been removed from the function destructuring. This creates an inconsistency where the type declares a parameter that is no longer used. The buttonIcon property should be removed from the ActionsMenuProps type definition to match the implementation.

Suggested change

buttonIcon?: string;

[Copilot]

Use cy.wait('@getManagedResources') and cy.wait('@getCRDs') instead of a hardcoded wait time. This makes the test more reliable and consistent with the other tests in this suite (lines 105-106 and 195-196). Hardcoded waits can lead to flaky tests and unnecessary delays.

Suggested change

	cy.wait(1000);
	cy.wait('@getManagedResources');
	cy.wait('@getCRDs');

[Copilot]

Consider reducing or removing the hardcoded waits (cy.wait(500), cy.wait(2000)) throughout the test file. Cypress generally handles element availability automatically with built-in retry logic. If waits are necessary, consider using more specific assertions or cy.waitUntil() to wait for specific conditions rather than arbitrary time periods, which can make tests slower and more brittle.

Suggested change

	cy.wait(2000);
	cy.then(() => {
	cy.log(`deleteCalled: ${deleteCalled}, patchCalled: ${patchCalled}`);
	});
	cy.then(() => cy.wrap(deleteCalled).should('equal', true));
	cy.then(() => cy.wrap(patchCalled).should('equal', true));
	cy.then(() => {
	cy.log(`deleteCalled: ${deleteCalled}, patchCalled: ${patchCalled}`);
	});
	cy.wrap(() => deleteCalled).should('equal', true);
	cy.wrap(() => patchCalled).should('equal', true);