Pull request
结果就在 pull request 上。
运行一开始，TestSprite 就会发一条评论，之后用结果更新这条评论：什么失败了、在哪一步、为什么。推送修复后，新的提交会再测一遍。
直接接入你现有的 CI。
由你的 CI 信号触发
粘贴一个最近的 pull request，TestSprite 会列出 CI 在上面做过的事：部署、workflow、check、状态、bot 评论。选出代表预览环境已就绪的那一个即可。
测试每个 PR 自己的预览环境
每个 pull request 都在自己的预览 URL 上运行，URL 由你设置一次的规则生成。推送到分支时，则测试你选定的环境。
失败即阻止合并
打开合并关卡后，运行失败会让 TestSprite 状态检查失败。把这个检查设为必需，pull request 就会一直等到它通过。
历史记录
每次运行都汇入同一份历史。
来自 pull request 的运行，和定时、手动、CLI 运行排在一起，跑的是同一套测试，保存方式也一样。检查变红时，点一下就能看到背后的那次运行。
配置
整个 workspace 只需安装一次。
安装一次 GitHub App，并精确选择它能访问哪些仓库。之后每个项目添加自己的触发器，下一个 pull request 就会被测试。
两种接入方式
GitHub App， 或流水线里的 CLI。
TestSprite 从不构建或部署你的应用。它测试的是你的 CI 已经做好的部署，从更适合你配置的那一侧接入。
GitHub App
适合预览部署
如果每个 pull request 都由 Vercel 或 Netlify 这样的平台部署，这是最佳选择。安装 App、添加触发器，结果就会以评论和状态检查的形式回到 PR 上。不需要写 workflow 文件。
GitHub 集成文档CLI
适合完全掌控流水线
在 GitHub Actions 或任何能运行 shell 命令的 CI 中，把 TestSprite CLI 作为一个步骤运行。运行没有通过，这个步骤就会失败；在 GitHub Actions 上，失败会显示在 pull request 上，JUnit XML 报告也可以接入 GitLab 或 Jenkins。
CI/CD 指南你可能想知道
常见问题
一个 GitHub 上的仓库，以及一个 TestSprite 云端能访问的部署：每个 pull request 的预览环境，或者某个分支部署到的环境。TestSprite 从不构建或部署你的应用，它测试的是你的 CI 已经做好的部署。