test(lightspeed): MCP servers e2e — mocked API, scenarios, en-only suite

[HusneShabbir]

Description:

The tests cover the following scenarios

1. Opening MCP settings from the chatbot — In overlay, dock, and fullscreen, you can open the MCP servers panel and the UI looks right (table, headings, buttons, and the panel closes cleanly).

2. When there are no MCP servers — The table shows the empty message.

3. When there are two servers, different situations — The list shows the right names and status text for: both healthy, one broken and one OK, one turned off and one on, or both needing a token.

4. Sorting by name — Clicking the Name column changes the order of the rows (e.g. alpha before beta, then reversed).

5. Turning a server on and off — Flipping the switch turns a server off (status shows Disabled) and turning it on again brings back the tool count line.

6. English-only for this block — Those MCP settings tests only run when the Playwright run is using the English locale, because Localization hasn't been done.

The rest of the Lightspeed file still has the older tests (chat, models, sidebar, etc.); the items above are what this MCP-focused work added or tightened.

---

Resolves:
https://redhat.atlassian.net/browse/RHIDP-12129

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
app-legacy	workspaces/lightspeed/packages/app-legacy	none	v0.0.1

[rhdh-qodo-merge]

Review Summary by Qodo

Add e2e tests for MCP settings across display modes

🧪 Tests

Walkthroughs

Description

• Add comprehensive e2e tests for MCP settings across all display modes
• Introduce POM helpers for opening, closing, and verifying MCP settings panel
• Extend display-mode menu snapshot to include MCP settings menu item
• Scope MCP table locators to avoid conflicts with catalog elements
• Skip File Attachment Validation test suite temporarily

Diagram

flowchart LR
  A["Test Suite"] -->|"Add MCP settings tests"| B["Overlay/Dock/Fullscreen modes"]
  C["POM Helpers"] -->|"openMcpSettingsPanel"| D["MCP Settings Panel"]
  C -->|"closeMcpSettingsPanel"| D
  C -->|"verifyMcpSettingsPanel"| E["Assertions & Snapshots"]
  F["Display Mode Menu"] -->|"Include MCP settings item"| G["Updated Snapshot"]

Loading

File Changes

1. workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts 🧪 Tests +27/-1

Add MCP settings e2e tests for all display modes

• Add new test suite Chatbot MCP settings with three test cases covering Overlay, Dock to window,
 and Fullscreen display modes
• Import new verifyMcpSettingsPanel helper function from LightspeedPage
• Skip File Attachment Validation test suite using test.describe.skip
• Each MCP settings test opens chatbot, optionally selects display mode, and verifies MCP panel

workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts

---

2. workspaces/lightspeed/packages/app-legacy/e2e-tests/pages/LightspeedPage.ts 🧪 Tests +66/-0

Add MCP settings POM helpers and menu snapshot

• Add MCP_SETTINGS_MENU_ITEM constant for the MCP settings menu label
• Implement openMcpSettingsPanel helper to open MCP settings via settings menu
• Implement closeMcpSettingsPanel helper to close MCP settings panel
• Implement verifyMcpSettingsPanel comprehensive helper that waits for list load, asserts panel
 visibility, table structure, column headers, and accessibility snapshots
• Update verifyDisplayModeMenuOptions snapshot to include MCP settings menu item
• Scope MCP table locators to avoid strict-mode conflicts with catalog elements

workspaces/lightspeed/packages/app-legacy/e2e-tests/pages/LightspeedPage.ts

---

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX Issues (0)

1. MCP loading check unsynced ☑ 🐞 ☼

Description

verifyMcpSettingsPanel waits for the text "Loading MCP servers..." to be hidden before asserting the
MCP panel has mounted, so the check can pass immediately when the panel hasn’t rendered yet. The
panel then mounts with the loading row visible (isLoading defaults to true), and later assertions
can run while still loading.

Code

workspaces/lightspeed/packages/app-legacy/e2e-tests/pages/LightspeedPage.ts[R113-121]

+  await openMcpSettingsPanel(page, t);
+
+  await expect(page.getByText('Loading MCP servers...')).toBeHidden({
+    timeout: 30_000,
+  });
+
+  const table = page.getByLabel('MCP servers table');
+  await expect(table).toBeVisible();
+  await expect(

Evidence

The helper calls expect(getByText('Loading MCP servers...')).toBeHidden() immediately after
clicking the menu item, before any assertion that the MCP heading/table is present. In the real UI,
McpServersSettings initializes isLoading to true and renders a row containing "Loading MCP
servers..." when loading, meaning the text is expected to appear on mount and must be synchronized
after the panel is visible/attached.

workspaces/lightspeed/packages/app-legacy/e2e-tests/pages/LightspeedPage.ts[113-127]
workspaces/lightspeed/plugins/lightspeed/src/components/McpServersSettings.tsx[258-262]
workspaces/lightspeed/plugins/lightspeed/src/components/McpServersSettings.tsx[499-507]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`verifyMcpSettingsPanel` checks that "Loading MCP servers..." is hidden before it verifies the MCP settings UI is actually rendered. If the MCP panel mounts after that assertion runs, the hidden check can incorrectly pass and the test proceeds without proper synchronization.

### Issue Context
`McpServersSettings` initializes `isLoading` to `true` and renders "Loading MCP servers..." while fetching, so the loading row is expected to appear right after mount.

### Fix Focus Areas
- workspaces/lightspeed/packages/app-legacy/e2e-tests/pages/LightspeedPage.ts[113-127]

### Suggested change
Reorder/synchronize like:
1) Assert the MCP panel is open (e.g., heading "MCP servers" or the table `aria-label="MCP servers table"` is visible).
2) Then wait for the loading row to disappear (optionally `toBeVisible()` first, then `toBeHidden()`, or scope it under the table: `table.getByText('Loading MCP servers...')`).
3) Finally, assert empty state or first data row.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Fixed sleep in E2E ☑ 🐞 ☼

Description

The fullscreen MCP settings test uses a hard-coded 1s timeout after switching display mode, making
the test timing-dependent and flaky in CI. It should wait on a deterministic post-transition UI
condition before continuing.

Code

workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[R213-217]

+    test('Fullscreen: MCP servers panel and header chrome', async () => {
+      await openChatbot(sharedPage);
+      await selectDisplayMode(sharedPage, translations, 'Fullscreen');
+      await sharedPage.waitForTimeout(1000);
+      await verifyMcpSettingsPanel(sharedPage, translations);

Evidence

The fullscreen MCP test uses waitForTimeout(1000) instead of waiting for an observable state
change; the same file already shows a deterministic way to validate fullscreen transition completion
(expectBackstagePageVisible(..., false)) in the fullscreen display-mode test.

workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[213-218]
workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[186-193]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The fullscreen MCP settings test sleeps for 1s after switching to fullscreen. This is flaky because the fullscreen transition time varies across machines/CI load.

### Issue Context
There is already an established deterministic check for fullscreen mode in the existing display mode tests (`expectBackstagePageVisible(page, false)`).

### Fix Focus Areas
- workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[213-218]

### Suggested change
Remove `waitForTimeout(1000)` and instead wait for a stable fullscreen indicator (for example reuse `await expectBackstagePageVisible(sharedPage, false)` or assert a fullscreen-specific DOM/state) before calling `verifyMcpSettingsPanel`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. File upload tests disabled ☑ 🐞 ⚙

Description

The PR changes the File Attachment Validation suite to test.describe.skip, removing file upload
validation coverage from CI and potentially hiding regressions. If this is intentional, it should be
replaced with a documented/targeted skip (e.g., fixme with a tracking issue) rather than disabling
the entire suite silently.

Code

workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[300]

+  test.describe.skip('File Attachment Validation', () => {

Evidence

The entire File Attachment Validation block is now skipped, which means the single-file and
multi-file upload validation tests in that block will no longer run.

workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[300-356]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
A whole E2E suite is disabled via `test.describe.skip`, reducing coverage unrelated to MCP settings.

### Issue Context
If these tests are flaky or blocked by a known issue, they should be skipped in a way that preserves intent and traceability.

### Fix Focus Areas
- workspaces/lightspeed/packages/app-legacy/e2e-tests/lightspeed.test.ts[300-356]

### Suggested change
Either:
- Remove `.skip` to restore coverage, or
- Replace with a targeted skip (`test.fixme(...)` / conditional skip) and add a comment linking to the tracking issue and the reason for disabling.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud