Sanity 项目中的 Playwright 拖拽交互测试从 Kanban 看板到 Canvas 画布的完整实战指南【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity拖拽交互drag-and-drop是现代富交互界面中最容易出现测试盲区的能力之一可排序列表、Kanban 看板、文件拖放区、画布编辑器中的坐标拖拽各有各的事件模型与状态语义。本篇以本仓库 .agents/skills/playwright-best-practices/testing-patterns/drag-drop.md 为核心骨架结合 Sanity 仓库中基于dnd-kit的数组列表排序实现list.tsx与 DragHandle.tsx 等源码证据系统讲解如何在 Playwright 中用dragTo()与底层page.mouse事件覆盖七类拖拽场景并给出可复制、可运行的 TypeScript 测试用例。读完本文你将掌握拖拽测试的选型判断、断言策略与防 flaky 技巧能够为任何基于原生 HTML5 DnD 或自定义拖拽库react-beautiful-dnd、dnd-kit、SortableJS的应用写出稳定的端到端测试。一、何时需要拖拽测试场景识别与策略选型拖拽交互测试的适用场景非常明确可排序列表、Kanban 看板、文件拖放区、可重定位元素。一旦应用中出现了这四类交互就应该建立对应的端到端测试。在动手写测试之前最关键的决策是选择拖拽实现方式——这直接决定测试代码的写法拖拽实现适用场景Playwright 测试方式原生 HTML5 Drag and Drop浏览器原生draggable属性、dragstart/drop事件优先使用locator.dragTo()一行搞定自定义拖拽库dnd-kit、react-beautiful-dnd、SortableJS需要增量mousemove事件序列使用page.mouse.down()/mouse.move()/mouse.up()手动模拟文件拖放区input[typefile]或自定义 drop 区域setInputFiles()或dispatchEvent模拟拖入状态Sanity 仓库本身就是这个决策树的绝佳实例其数组字段的排序功能基于dnd-kit实现。在 list.tsx 中数组列表通过useSensors(useSensor(PointerSensor), useSensor(KeyboardSensor, SENSOR_OPTIONS))同时注册了指针传感器与键盘传感器这意味着它既依赖连续的鼠标事件序列也支持键盘排序——测试时需要针对这两条路径分别覆盖。二、Kanban 看板测试跨列移动、流程流转与列内排序看板是拖拽测试的标准考题因为它在一次交互中同时涉及跨容器移动和容器内排序两种语义。2.1 跨列移动卡片核心思路用dragTo()完成拖拽然后用计数断言验证两侧列表都发生了变化import {test, expect} from playwright/test test(moves card between columns, async ({page}) { await page.goto(/board) const backlog page.locator([data-columnbacklog]) const active page.locator([data-columnactive]) const ticket backlog.getByText(Update API docs) await expect(ticket).toBeVisible() const backlogCountBefore await backlog.getByRole(article).count() const activeCountBefore await active.getByRole(article).count() await ticket.dragTo(active) await expect(active.getByText(Update API docs)).toBeVisible() await expect(backlog.getByText(Update API docs)).not.toBeVisible() await expect(backlog.getByRole(article)).toHaveCount(backlogCountBefore - 1) await expect(active.getByRole(article)).toHaveCount(activeCountBefore 1) })这段测试的关键点在于双向断言既验证目标列多了一张卡也验证源列少了一张卡。只断言一端很容易被拖拽事件触发了但状态未正确持久化这类 bug 蒙混过关。2.2 跨多个阶段推进卡片当看板代表工作流backlog → active → review → complete时可以串联多次拖拽并逐阶段断言中间状态test(progresses card through workflow stages, async ({page}) { await page.goto(/board) const cols { backlog: page.locator([data-columnbacklog]), active: page.locator([data-columnactive]), review: page.locator([data-columnreview]), complete: page.locator([data-columncomplete]), } await cols.backlog.getByText(Update API docs).dragTo(cols.active) await expect(cols.active.getByText(Update API docs)).toBeVisible() await cols.active.getByText(Update API docs).dragTo(cols.review) await expect(cols.review.getByText(Update API docs)).toBeVisible() await cols.review.getByText(Update API docs).dragTo(cols.complete) await expect(cols.complete.getByText(Update API docs)).toBeVisible() await expect(cols.backlog.getByText(Update API docs)).not.toBeVisible() await expect(cols.active.getByText(Update API docs)).not.toBeVisible() await expect(cols.review.getByText(Update API docs)).not.toBeVisible() })注意这里将各列定位器集中放在一个对象中既减少重复也让卡片从一个阶段走到另一个阶段的测试意图一目了然。2.3 列内排序同一列内重新排序时位置关系才是断言对象。利用allTextContents()拿到真实 DOM 顺序再比较目标项的相对索引test(reorders cards within same column, async ({page}) { await page.goto(/board) const backlog page.locator([data-columnbacklog]) const itemX backlog.getByRole(article).filter({hasText: Item X}) const itemZ backlog.getByRole(article).filter({hasText: Item Z}) await itemZ.dragTo(itemX) const cards await backlog.getByRole(article).allTextContents() expect(cards.indexOf(Item Z)).toBeLessThan(cards.indexOf(Item X)) })filter({hasText: ...})是对列表项进行按文本定位的推荐方式比脆弱的索引选择器健壮得多。而用indexOf比较相对顺序比断言必须出现在第 0 位更能容忍其他卡片的存在。2.4 验证拖拽结果通过 API 持久化拖拽测试最容易忽略的一环是持久化验证——界面变了不代表后端存了。用page.waitForResponse捕获拖拽触发的 PATCH 请求再通过page.reload()验证刷新后状态依然存在test(verifies drag persists via API, async ({page}) { await page.goto(/board) const backlog page.locator([data-columnbacklog]) const active page.locator([data-columnactive]) const responsePromise page.waitForResponse( (r) r.url().includes(/api/tickets) r.request().method() PATCH, ) await backlog.getByText(Update API docs).dragTo(active) const response await responsePromise expect(response.status()).toBe(200) const body await response.json() expect(body.column).toBe(active) await page.reload() await expect(active.getByText(Update API docs)).toBeVisible() })这段测试串起了拖拽动作 → 网络请求 → 响应内容 → 刷新后的最终状态整条链路能有效捕获那些只改了前端 state、没有同步到服务端的状态管理 bug。从源码结构看Sanity 的数组排序交互也是拖拽结束 → 计算 fromIndex/toIndex → 触发文档变更的调用链在 list.tsx 的handleDragEnd回调中通过active.data.current?.sortable?.index与over?.data.current?.sortable?.index计算出新旧索引并交给onItemMove——测试时若想验证排序持久化同样建议在拖拽后等待对应的 API 响应或重新加载页面。三、可排序列表测试dragTo()与增量鼠标移动3.1 基础重排test(reorders list items, async ({page}) { await page.goto(/priorities) const list page.getByRole(list, {name: Priority list}) const initial await list.getByRole(listitem).allTextContents() expect(initial[0]).toContain(Priority A) expect(initial[1]).toContain(Priority B) expect(initial[2]).toContain(Priority C) const priorityC list.getByRole(listitem).filter({hasText: Priority C}) const priorityA list.getByRole(listitem).filter({hasText: Priority A}) await priorityC.dragTo(priorityA) const reordered await list.getByRole(listitem).allTextContents() expect(reordered[0]).toContain(Priority C) expect(reordered[1]).toContain(Priority A) expect(reordered[2]).toContain(Priority B) })先断言初始顺序再断言重排后的顺序——这种前后对照让测试即使失败也能立刻看出拖拽是否真的生效。3.2 通过拖拽手柄drag handle重排许多列表包括 Sanity 的数组字段只允许通过专门的手柄拖动而不是整行可拖。此时要用宽松的正则匹配手柄的可访问名称test(reorders via drag handle, async ({page}) { await page.goto(/priorities) const list page.getByRole(list, {name: Priority list}) const handle list .getByRole(listitem) .filter({hasText: Priority C}) .getByRole(button, {name: /drag|reorder|grip/i}) const target list.getByRole(listitem).filter({hasText: Priority A}) await handle.dragTo(target) const items await list.getByRole(listitem).allTextContents() expect(items[0]).toContain(Priority C) })这个模式与 Sanity 的实现高度吻合Sanity 数组项的排序正是通过 DragHandle.tsx 渲染的专用手柄按钮完成的——它从useSortable({id, disabled: readOnly})中取出listeners与attributes并挂载到按钮上同时设置data-uiDragHandleButton便于测试定位。测试时如果手柄被readOnly禁用Playwright 的dragTo()会自然失败这本身就是对只读态不可拖拽约束的一种验证。3.3 重排后的持久化验证与看板同理排序结果应当刷新后依然成立test(reorder persists after reload, async ({page}) { await page.goto(/priorities) const list page.getByRole(list, {name: Priority list}) const priorityC list.getByRole(listitem).filter({hasText: Priority C}) const priorityA list.getByRole(listitem).filter({hasText: Priority A}) await priorityC.dragTo(priorityA) await page.waitForResponse( (response) response.url().includes(/api/priorities/reorder) response.status() 200, ) await page.reload() const items await list.getByRole(listitem).allTextContents() expect(items[0]).toContain(Priority C) expect(items[1]).toContain(Priority A) expect(items[2]).toContain(Priority B) })3.4 针对自定义拖拽库的增量鼠标移动这是全文最容易踩坑的地方像 react-beautiful-dnd、dnd-kit 这类拖拽库在拖拽过程中依赖连续的mousemove事件来触发排序预览与占位符重排。dragTo()内部通常只发送一次跳跃式的移动遇到这类库会静默失败——测试通过了但实际顺序根本没变。对策是手动模拟带中间步进的鼠标事件序列test(reorders with incremental mouse movements, async ({page}) { await page.goto(/priorities) const list page.getByRole(list, {name: Priority list}) const source list.getByRole(listitem).filter({hasText: Priority C}) const target list.getByRole(listitem).filter({hasText: Priority A}) const sourceBox await source.boundingBox() const targetBox await target.boundingBox() await source.hover() await page.mouse.down() const steps 10 for (let i 1; i steps; i) { await page.mouse.move( sourceBox!.x sourceBox!.width / 2, sourceBox!.y (targetBox!.y - sourceBox!.y) * (i / steps), {steps: 1}, ) } await page.mouse.up() const items await list.getByRole(listitem).allTextContents() expect(items[0]).toContain(Priority C) })这段代码用线性插值把从源元素到目标元素的中点移动拆成 10 步并在每步之间发送mousemove确保拖拽库收到完整的拖拽轨迹。Sanity 的排序实现同样属于这一类PointerSensor需要真实的事件流才能完成命中检测与排序策略计算因此在 Sanity 中测试数组字段排序时如果dragTo()不生效应当改用这种增量移动方案。四、原生 HTML5 拖拽测试dragTo()的主场当目标应用使用浏览器原生拖拽draggabledragstart/dragover/drop事件时dragTo()是最简单可靠的方案test(drags item to drop zone, async ({page}) { await page.goto(/drag-example) const source page.getByText(Movable Element) const dropArea page.locator(#target-zone) await expect(source).toBeVisible() await expect(dropArea).not.toContainText(Movable Element) await source.dragTo(dropArea) await expect(dropArea).toContainText(Movable Element) })4.1 双向往返拖拽在两个区域之间来回拖动验证两个方向的迁移都正确test(drags between zones, async ({page}) { await page.goto(/drag-example) const item page.locator([data-testidelement-1]) const areaA page.locator([data-testidarea-a]) const areaB page.locator([data-testidarea-b]) await expect(areaA).toContainText(Element 1) await item.dragTo(areaB) await expect(areaB).toContainText(Element 1) await expect(areaA).not.toContainText(Element 1) await areaB.getByText(Element 1).dragTo(areaA) await expect(areaA).toContainText(Element 1) await expect(areaB).not.toContainText(Element 1) })4.2 验证拖拽过程中的视觉反馈原生拖拽常通过 class 切换来呈现拖入高亮状态。这类中间态只能用底层鼠标事件逐步驱动并在拖放前断言test(verifies drag visual feedback, async ({page}) { await page.goto(/drag-example) const source page.getByText(Movable Element) const dropArea page.locator(#target-zone) await source.hover() await page.mouse.down() const dropBox await dropArea.boundingBox() await page.mouse.move(dropBox!.x dropBox!.width / 2, dropBox!.y dropBox!.height / 2) await expect(dropArea).toHaveClass(/drag-over|highlight/) await page.mouse.up() await expect(dropArea).not.toHaveClass(/drag-over|highlight/) await expect(dropArea).toContainText(Movable Element) })五、文件拖放区测试setInputFiles与拖入状态模拟文件上传的拖放在 E2E 中通常拆成两条路径真实文件输入与拖入视觉反馈。5.1 通过文件输入完成上传最稳妥的方式仍是命中底层input typefile并注入真实文件import {test, expect} from playwright/test import path from path test(uploads file via drop zone, async ({page}) { await page.goto(/upload) const dropZone page.locator([data-testidfile-drop-zone]) await expect(dropZone).toContainText(Drag files here) const fileInput page.locator(input[typefile]) await fileInput.setInputFiles(path.resolve(__dirname, ../fixtures/report.pdf)) await expect(page.getByText(report.pdf)).toBeVisible() await expect(page.getByText(/\d KB/)).toBeVisible() })5.2 用dispatchEvent模拟拖入高亮状态如果要验证文件悬停在拖放区上方时的高亮/提示文案这类纯视觉交互可以用dispatchEvent注入带dataTransfer的dragenter事件test(simulates drag-over visual feedback, async ({page}) { await page.goto(/upload) const dropZone page.locator([data-testidfile-drop-zone]) await dropZone.dispatchEvent(dragenter, { dataTransfer: {types: [Files]}, }) await expect(dropZone).toHaveClass(/drag-active|drop-highlight/) await expect(dropZone).toContainText(/drop.*here|release.*upload/i) await dropZone.dispatchEvent(dragleave) await expect(dropZone).not.toHaveClass(/drag-active|drop-highlight/) })5.3 拒绝非法文件类型文件拖放区的另一个核心职责是类型校验。setInputFiles支持直接构造内存中的文件对象无需真实磁盘文件test(rejects invalid file types, async ({page}) { await page.goto(/upload) const fileInput page.locator(input[typefile]) await fileInput.setInputFiles({ name: script.exe, mimeType: application/x-msdownload, buffer: Buffer.from(fake-content), }) await expect(page.getByRole(alert)).toContainText(/not allowed|invalid file type/i) await expect(page.getByText(script.exe)).not.toBeVisible() })六、Canvas 画布坐标拖拽boundingBox()驱动的精确定位画布类编辑器设计工具、图表、节点编排的拖拽对象不是可排序 DOM 节点而是坐标系中的位置。所有测试都建立在boundingBox()之上。6.1 拖到指定坐标并验证位置test(drags element to specific coordinates, async ({page}) { await page.goto(/design-tool) const canvas page.locator(#editor-canvas) const shape page.locator([data-testidshape-1]) const canvasBox await canvas.boundingBox() const targetX canvasBox!.x 300 const targetY canvasBox!.y 200 await shape.hover() await page.mouse.down() await page.mouse.move(targetX, targetY, {steps: 10}) await page.mouse.up() const newBox await shape.boundingBox() expect(newBox!.x).toBeCloseTo(targetX - newBox!.width / 2, -1) expect(newBox!.y).toBeCloseTo(targetY - newBox!.height / 2, -1) })断言时用toBeCloseTo(expected, -1)提供容差——坐标计算涉及浮点与取整精确相等断言几乎必然 flaky。6.2 网格吸附验证如果编辑器有网格吸附snap-to-grid可以拖到一个非对齐位置再断言最终坐标落在网格刻度上test(snaps element to grid, async ({page}) { await page.goto(/design-tool) const shape page.locator([data-testidshape-1]) const canvas page.locator(#editor-canvas) const canvasBox await canvas.boundingBox() await shape.hover() await page.mouse.down() await page.mouse.move(canvasBox!.x 147, canvasBox!.y 83, {steps: 10}) await page.mouse.up() const snappedBox await shape.boundingBox() expect(snappedBox!.x % 20).toBeCloseTo(0, 0) expect(snappedBox!.y % 20).toBeCloseTo(0, 0) })6.3 边界约束验证许多画布元素会被限制在容器内不允许拖出边界。测试方法把鼠标拖到远超容器范围的位置再断言元素四边都仍落在容器内test(constrains drag within boundaries, async ({page}) { await page.goto(/design-tool) const shape page.locator([data-testidbounded-shape]) const container page.locator(#bounds-container) const containerBox await container.boundingBox() await shape.hover() await page.mouse.down() await page.mouse.move(containerBox!.x containerBox!.width 500, containerBox!.y - 200, { steps: 10, }) await page.mouse.up() const shapeBox await shape.boundingBox() expect(shapeBox!.x).toBeGreaterThanOrEqual(containerBox!.x) expect(shapeBox!.y).toBeGreaterThanOrEqual(containerBox!.y) expect(shapeBox!.x shapeBox!.width).toBeLessThanOrEqual(containerBox!.x containerBox!.width) expect(shapeBox!.y shapeBox!.height).toBeLessThanOrEqual(containerBox!.y containerBox!.height) })这一测试模式与 Sanity 的拖拽边界约束实现相互印证Sanity 在 restrictToParentElementWithMargins.ts 中实现了自己的 dnd-kit Modifier通过比较draggingNodeRect与containerNodeRect来把拖拽 transform 限制在父容器范围内并支持margins微调随后在 list.tsx 中以restrictToParentElementWithMargins({y: 4})的形式组合进修饰器链。如果你要测试这类带边距约束的拖拽可以断言最终位置与容器边界之间恰好相差 4px。6.4 通过手柄调整尺寸画布编辑器中拖拽手柄改变元素尺寸本质也是坐标拖拽test(resizes element via handle, async ({page}) { await page.goto(/design-tool) const shape page.locator([data-testidshape-1]) await shape.click() const resizeHandle shape.locator(.resize-handle-se) const handleBox await resizeHandle.boundingBox() const initialBox await shape.boundingBox() await resizeHandle.hover() await page.mouse.down() await page.mouse.move(handleBox!.x 100, handleBox!.y 80, {steps: 5}) await page.mouse.up() const newBox await shape.boundingBox() expect(newBox!.width).toBeCloseTo(initialBox!.width 100, -1) expect(newBox!.height).toBeCloseTo(initialBox!.height 80, -1) })七、自定义拖拽预览测试拖拽中间态的正确断言现代拖拽库包括 dnd-kit在拖拽时会渲染自定义预览层或给源元素打上dragging/placeholderclass。这类中间态必须在鼠标释放之前断言test(shows custom drag preview, async ({page}) { await page.goto(/board) const card page.locator([data-testidticket-1]) const targetCol page.locator([data-columnactive]) const cardBox await card.boundingBox() const targetBox await targetCol.boundingBox() await card.hover() await page.mouse.down() const midX (cardBox!.x targetBox!.x) / 2 const midY (cardBox!.y targetBox!.y) / 2 await page.mouse.move(midX, midY, {steps: 5}) await expect(page.locator(.drag-preview)).toBeVisible() await expect(card).toHaveClass(/dragging|placeholder/) await page.mouse.move(targetBox!.x targetBox!.width / 2, targetBox!.y targetBox!.height / 2, { steps: 5, }) await page.mouse.up() await expect(page.locator(.drag-preview)).not.toBeVisible() })多选拖拽场景下预览层通常会显示拖动了几个条目test(multi-select drag shows item count, async ({page}) { await page.goto(/board) await page.locator([data-testidticket-1]).click() await page.locator([data-testidticket-2]).click({modifiers: [Shift]}) await page.locator([data-testidticket-3]).click({modifiers: [Shift]}) const card page.locator([data-testidticket-1]) const targetCol page.locator([data-columncomplete]) await card.hover() await page.mouse.down() const targetBox await targetCol.boundingBox() await page.mouse.move(targetBox!.x 50, targetBox!.y 50, {steps: 5}) await expect(page.locator(.drag-preview)).toContainText(3 items) await page.mouse.up() await expect(targetCol.locator([data-testidticket-1])).toBeVisible() await expect(targetCol.locator([data-testidticket-2])).toBeVisible() await expect(targetCol.locator([data-testidticket-3])).toBeVisible() })八、变化场景键盘排序、跨 iframe 拖拽与触屏拖拽8.1 键盘驱动排序可访问性要求拖拽必须提供键盘替代路径。Playwright 通过page.keyboard可以完整覆盖聚焦 → Space 拾起 → 方向键移动 → Space 放下test(reorders using keyboard, async ({page}) { await page.goto(/priorities) const list page.getByRole(list, {name: Priority list}) const priorityC list.getByRole(listitem).filter({hasText: Priority C}) await priorityC.focus() await page.keyboard.press(Space) await page.keyboard.press(ArrowUp) await page.keyboard.press(ArrowUp) await page.keyboard.press(Space) const items await list.getByRole(listitem).allTextContents() expect(items[0]).toContain(Priority C) })这条测试路径在 Sanity 中有直接对应的源码支撑前面提到的 list.tsx 注册了KeyboardSensor并配置coordinateGetter: sortableKeyboardCoordinates这意味着 Sanity 的数组排序同样支持键盘操作E2E 测试应当覆盖这条可访问性路径。8.2 主页面与 iframe 之间的跨帧拖拽拖拽的坐标系统是相对于视口的因此跨 iframe 拖拽时需要拿到 iframe 元素自身的视口坐标作为目标点再用page.mouse移动过去test(drags between main page and iframe, async ({page}) { await page.goto(/composer) const sourceWidget page.getByText(Component A) const iframe page.frameLocator(#preview-frame) const iframeElement page.locator(#preview-frame) const sourceBox await sourceWidget.boundingBox() const iframeBox await iframeElement.boundingBox() const targetX iframeBox!.x 100 const targetY iframeBox!.y 100 await sourceWidget.hover() await page.mouse.down() await page.mouse.move(targetX, targetY, {steps: 20}) await page.mouse.up() await expect(iframe.getByText(Component A)).toBeVisible() })注意跨 iframe 拖拽无法用dragTo()一步完成因为dragTo()的目标定位器与源不在同一文档上下文。此时必须拆成源元素 hover → mouse.down → 按 iframe 视口坐标移动 → mouse.up并在 iframe 的 frameLocator 内断言结果。这与本仓库 e2e 目录中 Playwright 项目的整体思路一致参见 e2e/README.md 的测试组织方式。8.3 移动端触屏拖拽移动端拖拽走的是touchstart/touchmove/touchend事件流。用dispatchEvent构造带touches数组的触摸事件即可test(drags via touch events, async ({page}) { await page.goto(/priorities) const list page.getByRole(list, {name: Priority list}) const source list.getByRole(listitem).filter({hasText: Priority C}) const target list.getByRole(listitem).filter({hasText: Priority A}) const sourceBox await source.boundingBox() const targetBox await target.boundingBox() await source.dispatchEvent(touchstart, { touches: [{clientX: sourceBox!.x 10, clientY: sourceBox!.y 10}], }) for (let i 1; i 5; i) { const y sourceBox!.y (targetBox!.y - sourceBox!.y) * (i / 5) await source.dispatchEvent(touchmove, { touches: [{clientX: sourceBox!.x 10, clientY: y}], }) } await source.dispatchEvent(touchend) const items await list.getByRole(listitem).allTextContents() expect(items[0]).toContain(Priority C) })关于触屏拖拽Sanity 源码里有一个非常值得借鉴的细节在 DragHandle.tsx 中拖拽手柄在启用状态下显式设置了touch-action: none——这是因为 dnd-kit 的PointerSensor依赖原生触摸输入如果不声明touch-action: none浏览器的默认滚动行为会抢走触摸事件导致移动端无法开始拖拽该问题对应 issue #12931。如果你测试的拖拽库同样基于 Pointer Sensor务必先确认应用为拖拽手柄设置了touch-action: none否则触屏测试会因滚动抢占而稳定失败。这一点在对应的单元测试 DragHandle.test.tsx 中也有明确覆盖。九、拖拽测试五条核心建议优先dragTo()失败再降级到手动鼠标事件。Playwright 的dragTo()能覆盖大多数原生 HTML5 拖拽只有遇到 react-beautiful-dnd、dnd-kit、SortableJS 这类需要特定事件序列的自定义库时才改用page.mouse.down()/move()/up()。给拖拽库加中间鼠标步进。react-beautiful-dnd 等库需要多次mousemove才能触发排序逻辑使用{steps: 10}或手动循环如 3.4 节的插值循环单次跳跃移动常常会静默失败。断言最终状态而不是拖拽事件发生了。验证 DOM 真实反映了变更——条目顺序、列内容、坐标位置。拖拽过程中的视觉反馈是次要的持久化后的状态才是核心。这也是本文 2.4 与 3.3 两节专门做刷新后验证的原因。坐标断言一律用boundingBox()toBeCloseTo()。画布编辑器或对位置敏感的拖放操作完成后获取新的 bounding box用toBeCloseTo的容差参数对比预期值避免浮点误差导致的偶发失败。拖拽后测试撤销CtrlZ。如果应用支持撤销验证拖拽可逆——这是捕获状态管理缺陷的高性价比用例拖拽改了 UI撤销必须把 DOM 与数据源一并还原。十、总结把拖拽测试写进你的回归体系拖拽是看起来简单、写起来处处是坑的交互类型。本文给出的完整路径是先用dragTo()快速覆盖原生拖拽 → 对自定义拖拽库切换到增量鼠标事件 → 用计数/顺序/坐标三种断言方式验证最终状态 → 通过waitForResponse与page.reload()确认持久化 → 最后补上键盘、跨 iframe 与触屏三种变化场景。这套方法论在本仓库中既有文档支撑drag-drop.md 属于 playwright-best-practices 技能包中Testing drag and drop的专项参考也有真实的源码场景可落地Sanity 基于 dnd-kit 的数组排序list.tsx、DragHandle.tsx提供了自定义库 拖拽手柄 键盘排序 边界约束 触摸支持的全部测试靶点其 E2E 测试目录e2e/tests与单元测试如 DragHandle.test.tsx、list.test.tsx也展示了仓库自身对这类交互的验证方式。将这些用例纳入回归体系后你的拖拽功能将不再依赖人工手测碰运气。【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考