Add Site Management UI integration tests

[gcsecsey]

Related issues

• Related to STU-1867
• companion to Add CLI integration test for site create (custom name, domain, HTTPS) #3947

How AI was used in this PR

Claude audited the existing renderer tests to find coverage gaps, and wrote the tests.

Proposed Changes

The Site Management e2e tests drive every action through the UI, which is slow, flaky, and couples coverage to the current renderer. As we discussed on the huddle, durable logic coverage will live in the CLI integration suite (#3947), which is UI-independent.

This PR lands a small set of UI IPC-mock tests as reference examples for the command-boundary pattern on the current renderer. These tests mount the real components and SiteDetailsProvider, mock only the IPC bridge, and assert the commands each user action generates.

• Covers all nine Site Management smoke-sheet rows, plus custom domain and HTTPS. The tests now only cover duplicate, delete, rename, and PHP version.
• Adds coverage for site duplication, since there is no studio site duplicate command for the CLI suite to test.
• The delete cases now run on every platform (the old e2e versions were skipped on Windows).
• These supersede the hook-boundary assertions in the sibling unit tests, which can be retired in a follow-up.

The existing real e2e suite (apps/studio/e2e/sites.test.ts) is untouched and keeps running on every OS for true app→CLI and cross-platform coverage. These will be retired only once the new UI and the CLI round-trips are green.

Testing Instructions

• Run the new tests:

npm test -- src/components/tests/content-tab-settings.actions.test.tsx src/modules/site-settings/tests/edit-site-details.actions.test.tsx

• Confirm all tests pass
• Run npm run typecheck and confirm there are no errors

Regression validation

I confirmed that these tests fail on a real regression and that they catch the same bug as the existing e2e suite. I made this change ran both suites:

diff --git a/apps/studio/src/hooks/use-delete-site.ts b/apps/studio/src/hooks/use-delete-site.ts
index 7cc117a1c..33055caa8 100644
--- a/apps/studio/src/hooks/use-delete-site.ts
+++ b/apps/studio/src/hooks/use-delete-site.ts
@@ -33,7 +33,7 @@ export function useDeleteSite() {

                if ( response === DELETE_BUTTON_INDEX ) {
                        try {
-                               await deleteSite( siteId, checkboxChecked );
+                               await deleteSite( siteId, ! checkboxChecked );
                        } catch ( error ) {
                                ipcApi.showErrorMessageBox( {
                                        title: __( 'Deletion failed' ),
EOF

Suite	Bug introduced (inverted delete-files flag)
Old e2e (sites.test.ts)
New UI integration tests

The existing unit tests mock the hook→IPC translation layer, so these aren't catching the introduced issue, only the existing e2e tests and the newly added integration tests are.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[Copilot]

Pull request overview

Adds fast jsdom-based UI integration tests for Studio’s Site Management flows by mounting real renderer components/providers and asserting the IPC commands emitted for each user action (supporting the CLI/UI split testing strategy for STU-1867).

Changes:

• Added UI action tests for creating sites (suggested/custom name, default/custom path, custom domain + HTTPS) asserting getIpcApi().createSite(...) calls.
• Added UI action tests for editing site details (rename + PHP version change) asserting getIpcApi().updateSite(...) calls.
• Added UI action tests for duplicate and delete flows asserting getIpcApi().copySite(...) / getIpcApi().deleteSite(...) calls.

Reviewed changes

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

File	Description
apps/studio/src/modules/site-settings/tests/edit-site-details.actions.test.tsx	New integration-style tests asserting IPC calls for edit-site save + PHP version change.
apps/studio/src/modules/add-site/tests/create-site.actions.test.tsx	New integration-style tests asserting IPC calls for multiple site creation variants.
apps/studio/src/components/tests/content-tab-settings.actions.test.tsx	New integration-style tests asserting IPC calls for duplicate + delete behaviors from the settings tab.

---

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

[gavande1]

Great work @gcsecsey, thank you for working on this. I like the overall approach and direction.

One suggestion: as a quick proof of concept, it would be nice to intentionally break something in the components and confirm these tests actually fail. That gives us confidence they catch real regressions and are not passing vacuously.

[gcsecsey]

Great work @gcsecsey, thank you for working on this. I like the overall approach and direction.

One suggestion: as a quick proof of concept, it would be nice to intentionally break something in the components and confirm these tests actually fail. That gives us confidence they catch real regressions and are not passing vacuously.

Good suggestion, thanks! I added a section on this to the description. I could introduce an error and catch it with both the existing e2e and the new UI tests, but not the existing unit tests. 👍

[gcsecsey]

Hey @fredrikekelund could you also take a look at the approach in this PR and in #3947 and let us know what you think? Thanks!

[fredrikekelund]

The actual test implementations here look pretty good to me. The IPC mocking is quite small, and is effectively quite similar to a nock interceptor, so I like that part.

Zooming out for a moment, though, I do wonder if it is really worth spending the time to refactor apps/studio E2E tests in this way if we expect to move to a new UI soon anyway?

The existing E2E tests are slow, but they do work well. It seems more valuable to either write similar tests for the new UI or work on actually migrating the app to the new UI.

I get that this PR in combination with #3947 is a kind of mock-end-to-end testing suite. It's an OK strategy for speedier CI runs, but not so good as to warrant replacing the existing E2E suite, IMO. We loose the true end-to-end part while spending time rewriting tests for a solution that'll most likely be scrapped soon anyway.

there is no studio site duplicate command for the CLI suite to test

Maybe worth adding a Linear issue?

[gavande1]

Thanks @fredrikekelund. Let me respond point by point, since this builds on what we landed on in the discussions.

I do wonder if it is really worth spending the time to refactor apps/studio E2E tests in this way if we expect to move to a new UI soon anyway?
We loose the true end-to-end part while spending time rewriting tests for a solution that'll most likely be scrapped soon anyway.

The IPC mocking here is layer 2 of the three layers we agreed on, not a replacement for the real e2e. The true end-to-end part is not lost: it stays in the focused real round-trips (create, start, delete) that keep running on every OS. That is the reduced smoke suite you said gives sufficient assurance alongside the integration tests, and it is where the real app-to-CLI and cross-OS coverage, including bugs like the Windows spawn issue, lives.

The existing E2E tests are slow, but they do work well.
not so good as to warrant replacing the existing E2E suite

Agreed, and nothing here replaces it. As we said in the discussions, the old suite runs in parallel until the new UI is live, and deleting it is gated on the new harness plus the real round-trips being green first, so there is no coverage gap.

On your strongest point, you are right. The new UI is expected to land soon, so these mocked UI tests are tied to a renderer with a short runway and the payoff of expanding layer 2 on the old UI is thin. The durable value is the CLI suite in #3947, which is UI-independent, and the command-boundary approach itself carries over to the new UI. Given that, the open question for this PR is whether to merge it as a cheap consolidation or hold it and put the effort into the new UI instead.

@wojtekn could you weigh in here and share your opinion?

cc @gcsecsey

[wojtekn]

@fredrikekelund @gavande1 it's worth adding that we will have both UIs working in parallel for a while (and possibly allow opt-in via a beta feature or similar), so having tests for both UIs makes sense.

I think it makes sense to merge the PR, but scoped down - just a few IPC-mock tests as reference examples rather than a full port of the suite.

To avoid spending too much time on tests that will be removed at some point, it makes sense to prioritize those in the following way:

1. Add new CLI integration tests (they will stay regardless of the UI chosen)
2. Add new UI tests with IPC mocks for old UI (just a few, to develop good practice examples)
3. Add/port new UI tests with IPC mocks from the old UI to the new UI
4. Remove the old UI tests along with the old UI (alternatively, remove them as soon as we add the corresponding CLI tests mentioned in 1)

Also, to be clear, we are accepting that most of the UI-flow coverage gets dropped in favor of CLI logic coverage.

[gcsecsey]

@fredrikekelund @gavande1 it's worth adding that we will have both UIs working in parallel for a while (and possibly allow opt-in via a beta feature or similar), so having tests for both UIs makes sense.

I think it makes sense to merge the PR, but scoped down - just a few IPC-mock tests as reference examples rather than a full port of the suite.

To avoid spending too much time on tests that will be removed at some point, it makes sense to prioritize those in the following way:

1. Add new CLI integration tests (they will stay regardless of the UI chosen)
2. Add new UI tests with IPC mocks for old UI (just a few, to develop good practice examples)
3. Add/port new UI tests with IPC mocks from the old UI to the new UI
4. Remove the old UI tests along with the old UI (alternatively, remove them as soon as we add the corresponding CLI tests mentioned in 1)

Also, to be clear, we are accepting that most of the UI-flow coverage gets dropped in favor of CLI logic coverage.

I reduced the scope of this PR and updated the PR description.