-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test(e2e): add ip-address UI e2e test #72
Conversation
WalkthroughThe pull request introduces a new test file Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
tests/ip-address/xdesign.spec.ts (4)
3-3
: Test suite structure is well-organized.The test cases are logically grouped and cover different aspects of the IpAddress component. However, consider using English for test titles to maintain consistency with the code language.
Consider changing the test suite title to English, for example:
-test.describe('IpAddress组件xdesign规范', () => { +test.describe('IpAddress Component XDesign Specification', () => {
4-16
: Well-structured test case for default UI and hover state.The test case effectively covers both the default state and hover interaction of the IpAddress component. Error handling and screenshot capturing are implemented correctly.
Consider adding a short wait time after the hover action to ensure the UI has fully updated before capturing the screenshot:
await ipInput.hover() +await page.waitForTimeout(500) // Add a short delay to allow for any UI updates await expect(demo).toBeInViewport() await expect(demo).toHaveScreenshot('hover.png')
27-33
: Size variations test case is good, but could be more comprehensive.The test case for size variations of the IpAddress component follows the established structure and correctly implements error handling and screenshot capturing.
Consider enhancing this test to verify each size variation individually:
test('Size variations--UI screenshot', async ({ page }) => { page.on('pageerror', (exception) => expect(exception).toBeNull()) await page.goto('ip-address#size') const demo = page.locator('#size .pc-demo') await expect(demo).toBeInViewport() const sizes = ['mini', 'small', 'medium', 'large'] for (const size of sizes) { const sizeDemo = demo.locator(`.tiny-ip-address--${size}`) await expect(sizeDemo).toBeVisible() await expect(sizeDemo).toHaveScreenshot(`size-${size}.png`) } })This approach ensures that each size variation is visible and captured in a separate screenshot.
1-34
: Overall, excellent test structure with room for minor enhancements.The test file is well-organized, consistent, and covers key aspects of the IpAddress component. It follows Playwright best practices and provides good coverage of different component states.
Consider the following enhancements to further improve the test suite:
- Add a test case for error states (e.g., invalid input).
- Include keyboard navigation tests to ensure accessibility.
- Test any custom events or callbacks the component might emit or accept.
Example structure for an error state test:
test('Error state--UI screenshot', async ({ page }) => { page.on('pageerror', (exception) => expect(exception).toBeNull()) await page.goto('ip-address#basic-usage') const demo = page.locator('#basic-usage .pc-demo') const ipInput = demo.locator('.tiny-ip-address__input').first() await ipInput.fill('999.999.999.999') await ipInput.blur() await expect(demo).toHaveScreenshot('error-state.png') const errorMessage = demo.locator('.tiny-ip-address__error-message') await expect(errorMessage).toBeVisible() await expect(errorMessage).toHaveText('Invalid IP address') })These additions would provide more comprehensive coverage of the component's functionality and edge cases.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (4)
tests/ip-address/xdesign.spec.ts-snapshots/basic-usage-chromium-win32.png
is excluded by!**/*.png
tests/ip-address/xdesign.spec.ts-snapshots/disabled-chromium-win32.png
is excluded by!**/*.png
tests/ip-address/xdesign.spec.ts-snapshots/hover-chromium-win32.png
is excluded by!**/*.png
tests/ip-address/xdesign.spec.ts-snapshots/size-chromium-win32.png
is excluded by!**/*.png
📒 Files selected for processing (1)
- tests/ip-address/xdesign.spec.ts (1 hunks)
🔇 Additional comments (2)
tests/ip-address/xdesign.spec.ts (2)
1-1
: LGTM: Imports are correct and concise.The necessary Playwright test utilities are imported correctly.
18-25
: LGTM: Disabled state test case is well-implemented.The test case for the disabled state of the IpAddress component is correctly structured and consistent with the previous test. It appropriately checks for errors, verifies visibility, and captures a screenshot without attempting interactions on the disabled component.
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
IpAddress
component, covering default, disabled, and size variations.