test: migrate feedback tests from IQE (RHCLOUD-44391)#305
test: migrate feedback tests from IQE (RHCLOUD-44391)#305catastrophe-brandon wants to merge 22 commits intoRedHatInsights:masterfrom
Conversation
Summary by CodeRabbit
WalkthroughTwo new Playwright E2E test specifications are added: one verifying the help-panel feedback UI submission flow with success message validation, and another testing support-case functionality including tab navigation, external link opening, and pagination verification. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
Migrates support case help panel tests from iqe-platform-ui-plugin test_support_case.py to Playwright. Tests verify: - "Open a support case" button appears in help panel support tab - Clicking button opens Red Hat Customer Portal in new tab - Support cases table displays when user has open cases The tests handle both empty state (no cases) and populated state (with cases) gracefully using conditional skipping based on what's rendered. Note: The complex test_support_case_from_apps (testing pre-filled support case data from different apps) was not migrated as it requires cross-domain testing and is better suited for the insights-chrome repository. Requirements: - PLATFORM_UI-INSIGHTS_CHROME - PLATFORM_UI-SUPPORT_CASES Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Define timeout constants at module level for better maintainability - Replace page.waitForTimeout() with Playwright's expect().toPass() pattern - Use auto-retry for waiting on API-loaded content - Explicitly specify timeouts on assertions for clarity Timeout constants: - SUPPORT_API_LOAD_TIMEOUT (15s) - Support cases API load time - ELEMENT_VISIBLE_TIMEOUT (10s) - Element visibility wait - EXTERNAL_PAGE_LOAD_TIMEOUT (30s) - External page navigation Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Simplifies all three tests to follow the actual user interaction flow:
1. Click help button to open help panel
2. Wait for help panel to load
3. Click on support tab
4. Verify expected content is visible
Key improvements:
- Removed complex conditional logic and state checking
- Tests now follow clear step-by-step user flow with numbered comments
- Uses getByRole('link') to find 'Open a support case' link (works in both states)
- Removed unnecessary empty state vs table differentiation in first two tests
- Third test uses .or() locator for cleaner either/or waiting
The 'Open a support case' link is always visible:
- In empty state: as a primary action button
- With cases: as a link in the description text
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The 'Open a support case' element is rendered differently depending on state:
- Empty state (no cases): PatternFly Button with OUIA ID
- Populated state (has cases): Actual link in description text
Updated selectors to use .or() locator to find either:
- Button: [data-ouia-component-id="help-panel-open-support-case-button"]
- Link: getByRole('link', { name: /open a support case/i })
This makes tests work regardless of whether user has support cases.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…/link The SupportPanel shows a SkeletonTable while fetching support cases from the API. We need to wait for this loading state to complete before looking for the 'Open a support case' button/link. Changes: - Added step to wait for either empty state or table to appear (skeleton gone) - Only then check for the button/link visibility - This ensures we're not checking while the loading skeleton is still showing - Removed timeout from final visibility check since we already waited for loading Step flow now: 1. Click help button 2. Wait for help panel 3. Click support tab 4. Wait for loading to complete (empty state or table appears) 5. Verify button/link is visible 6-8. (Test 2 only) Click and verify new tab Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replace dual locator approach (OUIA ID + role) with simple text search. The text 'Open a support case' is the same whether rendered as a Button or Link, so searching by text is cleaner and more maintainable.
Change URL validation to check only the hostname (access.redhat.com) rather than the full path, since we cannot validate page content due to authentication requirements on the external Customer Portal. Also removed unnecessary waitForLoadState and unused timeout constants.
Clarify that test_support_case_from_apps requires complex setup: - API-created support cases - Cross-domain interaction - External portal authentication - Pre-filled data validation May require separate E2E suite or insights-chrome repository.
1. Add waitForURL before asserting hostname to ensure navigation completes (newPage starts at about:blank after pagePromise resolves) 2. Remove try/catch that hides real failures by converting timeouts to skips - Let API load failures fail the test naturally - Only skip when empty state is actually visible (user has no cases) - Removes false negatives from timeout/network issues
Replace broad wildcard waitForURL('**/*') with specific RegExp
/access\.redhat\.com/ to await popup navigation precisely and
fail faster if navigation goes to wrong domain.
Migrated from IQE: iqe_platform_ui/tests/test_feedback.py Test 1 (test_feedback_open): - Opens help panel - Navigates to Share feedback tab - Clicks Share feedback card - Verifies form is visible - Clicks Back button - Verifies return to feedback home Test 2 (test_feedback_submission): - Currently skipped - requires JIRA API integration - TODO: Implement JIRA client to verify ticket creation - Only runs on stage environment Requirements: - PLATFORM_UI-FEEDBACK - PLATFORM_UI-INSIGHTS_CHROME
Updated test_feedback_submission to only verify the form submission succeeds and displays success message, without requiring JIRA API integration for ticket verification. Changes: - Renamed test to 'should submit feedback successfully' - Removed JIRA API TODO and test.skip - Verifies 'Feedback sent' success message - Verifies 'Thank you' description - Verifies 'Share more feedback' button appears - Added note about manual JIRA ticket verification if needed - Runs on stage and prod environments only
Replace getByText('Tell us about your experience') with OUIA ID
locator to avoid strict mode violation from duplicate auto-generated
OUIA IDs.
Changes:
- Use locator('[data-ouia-component-id="feedback-home-title"]')
- Reuse the locator variable for both assertions
- Fixes: strict mode violation with 2 matching elements
Replace regex pattern getByLabel(/^(Describe|Share)/i) with exact
aria-label getByLabel('Feedback text') to correctly target the
textarea element instead of matching the tab panel.
The TextArea component uses aria-label="Feedback text" from
messages.feedbackAriaLabel.
Replace aria-label selector with ID-based selector and add explicit
wait for textarea visibility after clicking Share feedback card.
Changes:
- Use page.locator('#feedback-description-text') instead of getByLabel()
- Add await expect(feedbackTextarea).toBeVisible() before filling
- Ensures form transition completes before interaction
- Applied to both tests for consistency
The textarea ID is more reliable than aria-label which may vary
with localization.
Add explicit wait for feedback subtab to be visible before attempting to click it. The subtabs may not be immediately visible when the help panel first opens. This ensures the tab panel has fully rendered before interaction.
Merged test_feedback_open and test_feedback_submission into one test that covers the full user journey: 1. Opens help panel and navigates to feedback tab 2. Verifies feedback home page 3. Opens Share feedback form 4. Tests Back button navigation (returns to home) 5. Re-opens form 6. Fills and submits feedback 7. Verifies success message 8. Verifies 'Share more feedback' button Benefits: - Eliminates duplicate setup/navigation code - Tests complete user flow in one scenario - Runs only on stage/prod (where submission works) - Still covers all functionality from both original IQE tests Migrated from IQE: - test_feedback_open (@pytest.mark.qa) - test_feedback_submission (@pytest.mark.core)
a5ae4f4 to
c6cd63f
Compare
Updated comment to clarify that the test DOES run locally because the local dev server uses stage.foo.redhat.com:1337 as the hostname, which includes 'stage'. The test only skips on truly local URLs like localhost or 127.0.0.1.
Remove the hostname-based skip condition. The test now runs on all environments. If feedback submission isn't available (non-stage/prod), the test will fail naturally rather than silently skip. This simplifies the test and makes failures more obvious.
The card title is 'Share general feedback' not 'Share feedback'. Updated both instances where we click the card (steps 5 and 8). This was causing the click to fail silently since the locator couldn't find the element with the incorrect text.
1. Add exact: true to Back button locator to avoid strict mode violation - Prevents partial matches with 'Feedback' and 'Submit feedback' 2. Update success message to match actual text - Changed from 'Feedback sent' to 'feedback shared successfully' - Use case-insensitive regex for flexibility
Added timeout constants at the top of the test file: - PAGE_LOAD_TIMEOUT = 60000ms (initial page load) - FEEDBACK_SUBMISSION_TIMEOUT = 10000ms (feedback API submission) Replaced hard-coded values: - page.goto timeout: 60000 → PAGE_LOAD_TIMEOUT - Success message visibility: 10000 → FEEDBACK_SUBMISSION_TIMEOUT This improves maintainability and makes timeout values easy to adjust in one place.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@playwright/support-case.spec.ts`:
- Around line 56-61: The test assumes the "Open a support case" CTA is always
present but the SupportPanel renders that CTA only in empty-state; update the
spec to branch on which locator is visible: use the existing emptyState and
supportTable locators (emptyState, supportTable) to await visibility, then if
emptyState.isVisible() assert page.getByText(/open a support
case/i).toBeVisible(), else assert the CTA is not present or instead assert the
supportTable has expected rows; reference the SupportPanel component behavior
(src/components/HelpPanel/HelpPanelTabs/SupportPanel) when adding the
conditional assertion so tests are deterministic for accounts with open cases.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 40cb5586-615c-4875-8d96-8b92e55b1701
📒 Files selected for processing (2)
playwright/feedback.spec.tsplaywright/support-case.spec.ts
| const emptyState = page.locator('[data-ouia-component-id="help-panel-support-empty-state"]'); | ||
| const supportTable = page.locator('[data-ouia-component-id="help-panel-support-cases-table"]'); | ||
| await expect(emptyState.or(supportTable)).toBeVisible({ timeout: SUPPORT_API_LOAD_TIMEOUT }); | ||
|
|
||
| // Step 5: The "Open a support case" button/link should now be visible | ||
| await expect(page.getByText(/open a support case/i)).toBeVisible(); |
There was a problem hiding this comment.
State-dependent CTA assumption makes these tests nondeterministic.
After Line 58 / Line 81 you allow either state, but Line 61 and Line 87 still assume "Open a support case" exists. In src/components/HelpPanel/HelpPanelTabs/SupportPanel.tsx:153-236, that CTA is rendered only for empty-state. Accounts with open cases will fail these tests even when behavior is correct.
Suggested fix
@@
- await expect(emptyState.or(supportTable)).toBeVisible({ timeout: SUPPORT_API_LOAD_TIMEOUT });
-
- // Step 5: The "Open a support case" button/link should now be visible
- await expect(page.getByText(/open a support case/i)).toBeVisible();
+ await expect(emptyState.or(supportTable)).toBeVisible({ timeout: SUPPORT_API_LOAD_TIMEOUT });
+ const openSupportCaseCta = page.locator('[data-ouia-component-id="help-panel-open-support-case-button"]');
+ if (await emptyState.isVisible()) {
+ await expect(openSupportCaseCta).toBeVisible();
+ } else {
+ await expect(supportTable).toBeVisible();
+ test.skip('Open a support case CTA is only present in empty-state view.');
+ }
@@
- await expect(emptyState.or(supportTable)).toBeVisible({ timeout: SUPPORT_API_LOAD_TIMEOUT });
+ await expect(emptyState.or(supportTable)).toBeVisible({ timeout: SUPPORT_API_LOAD_TIMEOUT });
+ const openSupportCaseCta = page.locator('[data-ouia-component-id="help-panel-open-support-case-button"]');
+ if (!(await emptyState.isVisible())) {
+ test.skip('Open a support case CTA is only present in empty-state view.');
+ }
@@
- await page.getByText(/open a support case/i).click();
+ await openSupportCaseCta.click();Also applies to: 79-88
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@playwright/support-case.spec.ts` around lines 56 - 61, The test assumes the
"Open a support case" CTA is always present but the SupportPanel renders that
CTA only in empty-state; update the spec to branch on which locator is visible:
use the existing emptyState and supportTable locators (emptyState, supportTable)
to await visibility, then if emptyState.isVisible() assert page.getByText(/open
a support case/i).toBeVisible(), else assert the CTA is not present or instead
assert the supportTable has expected rows; reference the SupportPanel component
behavior (src/components/HelpPanel/HelpPanelTabs/SupportPanel) when adding the
conditional assertion so tests are deterministic for accounts with open cases.
There was a problem hiding this comment.
Not needed. The test account will not have any open cases because it is an isolated account used for this automation only.
There was a problem hiding this comment.
@catastrophe-brandon, understood — thanks for the context! Since the automation uses a dedicated, isolated account with no existing support cases, the empty-state is guaranteed and the CTA will always be present. That makes the current assertion perfectly deterministic for this setup.
📝 Learnings were identified and not saved (knowledge base disabled). Enable
Summary
Migrates feedback tests from IQE
test_feedback.pyto Playwright.Migrated from IQE
iqe_platform_ui/tests/test_feedback.pyTests Migrated
Test 1: should open and close feedback form
Markers:
@pytest.mark.qaTest 2: should submit feedback successfully
Markers:
@pytest.mark.coreNote: Only runs on stage/prod environments where submission is enabled.
What's NOT Migrated
Requirements
Related