# taro-react-miniprogram-automator

**Repository Path**: shixinde/taro-react-miniprogram-automator

## Basic Information

- **Project Name**: taro-react-miniprogram-automator
- **Description**: 2193809128309128390123
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-01-07
- **Last Updated**: 2026-02-10

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# miniprogram-automator（微信小程序自动化测试）Demo 基线说明


## 项目启动
安装依赖：`pnpm install`

启动项目：`pnpm dev:weapp`

运行测试：`pnpm test:e2e`




## 快速开始

本仓库用于基于 `miniprogram-automator` 搭一个可跑通的微信小程序 UI 自动化测试 demo。

`miniprogram-automator` 是面向微信小程序的自动化测试 JS SDK。它通过驱动「微信开发者工具」来启动/打开小程序页面，并在页面上做查找元素、点击、输入、等待等操作，从而实现端到端（E2E）的自动化测试。

---

## 它能做什么（能力范围）

典型能力（以开发者工具环境为主）：

- 启动/关闭小程序：指定微信开发者工具 CLI 路径与小程序工程路径，拉起 devtools 并连接自动化能力
- 页面级操作：打开页面、重新进入页面、等待一段时间（用于异步渲染/请求）
- 元素定位与查询：按选择器查找元素（常见为 class/id/标签等），获取元素属性
- 交互模拟：点击/轻触（tap）、表单类交互（如输入框输入，取决于页面实现）
- 断言与状态验证：通过元素属性、文本、展示状态等判断业务是否符合预期
- 用例编排：将登录、下单、支付前流程（不含真实支付）等串成回归用例

你可以把它理解为：在「开发者工具」里跑的小程序版 E2E 测试框架。

---

## 适合用它跑哪些测试

它最适合覆盖“用户视角”的关键链路与基础回归：

- 冒烟测试：启动是否成功、首页是否正常渲染、关键按钮可点击
- 核心链路 E2E：登录/授权（在 devtools 条件下）、搜索、加购、提交表单等
- 回归测试：页面改动后，确保核心路径不被破坏
- 组件/页面行为验证：列表展开、tab 切换、弹窗展示/关闭等

不太适合或收益较低的场景：

- 单元测试/纯逻辑测试：更适合用小程序自身的逻辑测试方案或通用 JS 测试框架
- 极致性能/真机兼容：它主要在开发者工具环境运行，无法替代真机测试矩阵

---

## 你需要准备什么（前置条件）

1. Node.js 环境（建议使用 LTS 版本）
2. 微信开发者工具（需要安装在本机）
3. 小程序项目源码（本地可用工程路径）
4. 开发者工具的 CLI 路径（例如 devtools 的可执行文件路径）

最小可运行形态是：

- 你有一个可在微信开发者工具打开并运行的小程序工程
- 你能提供开发者工具 CLI 路径与项目路径
- 用脚本拉起 devtools 并通过 SDK 进行页面操作

---

## 基本用法（最小示例）

下面示例展示如何启动、进入页面、查找元素并点击：

```js
const automator = require('miniprogram-automator')

;(async () => {
  const miniProgram = await automator.launch({
    cliPath: 'path/to/cli',
    projectPath: 'path/to/project',
  })

  const page = await miniProgram.reLaunch('/page/component/index')
  await page.waitFor(500)
  const element = await page.$('.kind-list-item-hd')
  console.log(await element.attribute('class'))
  await element.tap()
  await page.waitFor(200)
  console.log(await element.attribute('class'))

  await miniProgram.close()
})()
```

你后续做 demo 时，通常会把 `cliPath` / `projectPath` 抽到配置里，并在用例里统一初始化与清理。

---

## 运行形态建议（用于后续 demo 的组织方式）

当你基于本 README 去做 demo，建议按下面结构组织（仅为建议，不要求一模一样）：

- `tests/`
  - `e2e/`：端到端用例
  - `helpers/`：启动/关闭、等待、通用选择器等封装
- `config/`
  - `local.*`：本机运行需要的路径配置（避免写死在用例里）

用例编写思路：

- 每条用例只做一件事：例如“打开首页并展示列表”、“搜索后展示结果”
- 尽量用稳定选择器：避免依赖会变的文本或层级结构
- 关键步骤加等待：异步渲染/网络请求后，等元素出现再断言

---

## 主要限制与注意事项（非常重要）

1. **依赖微信开发者工具**
   - 自动化运行依托 devtools 环境，而非真实用户设备
   - 运行环境差异（真机、不同系统版本、不同微信版本）不在覆盖范围内

2. **路径与本机环境强相关**
   - `cliPath`、`projectPath`、devtools 安装位置、系统权限都会影响是否能启动
   - CI 上跑需要额外处理“安装 devtools / 图形界面 / 权限”的问题

3. **能力边界由 devtools 提供**
   - 能做的交互与可观测信息范围，取决于 devtools 暴露的自动化接口
   - 某些系统能力、授权弹窗、硬件相关能力（摄像头/蓝牙等）在自动化下可能受限

4. **更偏 UI 回归，不是全能测试**
   - 它擅长验证“看得到、点得动、流程不挂”
   - 不替代单元测试、接口测试、真机兼容与性能专项

---

x