AssppWeb测试体系指南：从Vitest单元测试到Playwright E2E零信任验证

AssppWeb测试体系指南从Vitest单元测试到Playwright E2E零信任验证【免费下载链接】AssppWeb项目地址: https://gitcode.com/gh_mirrors/as/AssppWebAssppWeb 是一款支持 Apple ID 认证、App 搜索与 IPA 侧载安装的开源 Web 工具其最大特色是零信任架构——服务器永远看不到你的 Apple 凭据。正因如此它的测试体系也格外值得学习从基于Vitest的前后端单元测试到Playwright E2E 端到端测试再到一条会扫描后端日志的零信任验证流水线。本文带你用最少的时间理解并跑通 AssppWeb 的完整测试体系。为什么 AssppWeb 需要多层测试体系普通 Web 应用的测试往往止步于页面能不能打开但 AssppWeb 涉及三条关键链路Apple 协议链路Bag 拉取 → 认证 → 购买授权 → 下载信息任何一步字段错位都会导致登录失败Wisp 隧道链路浏览器经 WebSocket 把 TLS 加密流量盲中继到 Apple 服务器路径白名单和端口限制必须严格IPA 编译链路服务端注入 SINF 与 iTunesMetadata 后生成可安装 IPA。为此项目采用三层防护文档见 AGENTS.md层级工具环境验证目标单元测试VitestNodebackend/tests/配置、路由、中间件、SINF 注入等纯逻辑单元测试Vitestjsdomfrontend/tests/Apple 协议、状态管理、组件渲染E2E 测试Playwrighte2e/目录Docker 内运行真实页面 真实 Wisp 隧道全链路零信任验证日志扫描e2e/docker-test.sh确认后端日志中无凭据泄漏一分钟跑通 Vitest 单元测试两个端都用 Vitest命令对新手非常友好——先装依赖再执行test脚本后端Node 环境下的单元测试cd backend npm install npm test # 等价于 npx vitest run后端测试运行在 Node 环境超时放宽到 30 秒见 backend/vitest.config.ts。其中最有代表性的 wsProxy.test.ts 会真正启动一个 Express WebSocket 服务器验证两点/wisp/路径接受连接而/proxy?...、/other等非法路径被拒绝——这正是零信任架构的边界防线。前端jsdom 内存版 IndexedDBcd frontend npm install npm test # 等价于 npx vitest run前端配置见 frontend/vitest.config.ts使用jsdom模拟浏览器并通过 setup 文件注入三种替身frontend/tests/setup.tsfake-indexeddb内存版 IndexedDB让凭据存储逻辑无需真实浏览器jest-dom 断言toBeInTheDocument()等组件断言localStorage / crypto mock补齐 jsdom 缺失的浏览器 API。这套组合让 authenticate.test.ts 这类协议测试成为可能mock 掉网络请求后精确断言认证 URL 中guid参数只被设置了一次、原有查询参数未被破坏。单元测试覆盖清单20 个测试文件后端7 个文件位于 backend/tests/wsProxy.test.ts— Wisp 隧道路径白名单 ✅bagRoute.test.ts— Bag 代理路由只返回公开 Apple 服务地址routes.test.ts— API 路由行为middleware.test.ts— 访问密码、HTTPS 跳转等中间件sinfInjector.test.ts— IPA 的 SINF 注入manifestBuilder.test.ts— itms-services 安装清单生成config.test.ts— 环境变量与常量配置前端13 个文件位于 frontend/tests/按模块组织apple/— 协议层认证、Bag、plist 编解码、Cookie 合并、端点配置store/— Zustand 状态账号管理、设置components/— React 组件渲染与交互utils/— 版本号比较、格式化工具api/— API 客户端封装Playwright E2E 端到端测试怎么跑单元测试无法覆盖浏览器里真实发生的事所以项目用 Playwright 在完整部署环境上做 E2E 测试有三种跑法本地一键Docker 端口 8080# 先在宿主机用 Docker 起好应用8080 端口 docker compose up -d cd e2e pnpm testDocker 官方镜像内测试compose.yml的testprofile 内置了 Playwright 服务它运行在官方mcr.microsoft.com/playwright镜像中通过 Docker 内部 DNS 访问应用docker compose --profile test run --rm playwright完整流水线构建 测试 零信任验证bash e2e/docker-test.sh这条命令是整套体系的高光时刻它先构建镜像、跑完 E2E最后扫描后端日志确认其中没有 Apple 凭据、password token 或 cookie——用自动化方式证明服务器真的只是个盲中继。 两个工程细节E2E 用例统一从./fixtures导入而非直接使用playwright/test便于注入统一夹具WebSocket 相关测试用location.host动态推导地址同一份代码在本地localhost:8080和 Dockerasspp:8080下都能跑。E2E 测试都覆盖了哪些场景场景验证点Wisp 代理/wisp/接受 WebSocket非 wisp 路径被拒绝添加账号流程设备 ID 字段、随机生成按钮、认证成功账号详情设备 ID、pod 展示设置页不存在全局设备 ID 区块按账号隔离搜索/Bundel ID 查询iTunes 字段映射正确性下载 APIiTunesMetadata 支持与向后兼容零信任验证用真实账号证明看不到文档记录了一次真实账号的 Docker 验证2026-02-22认证请求经 Wisp 隧道成功完成而后端日志中只有连接和流的元数据——没有凭据、没有 token、没有 cookie。对新手来说这种把安全承诺写成可执行测试的思路非常值得借鉴零信任不是写在 README 里的口号而是 AGENTS.md 中一段可以被任何人复现的验证脚本。测试账号安全凭据只放环境变量E2E 需要的真实测试凭据通过环境变量注入严禁提交进仓库变量用途TEST_EMAIL/TEST_PASSWORD测试 Apple IDTEST_DEVICE_ID测试设备标识TEST_BUNDLE_ID搜索场景使用的 Bundle ID快速上手清单✅ 克隆仓库后backend与frontend各自npm install npm test5 分钟内看到全部单元测试结果✅ 用 Docker Compose 启动应用再进入e2e/执行 Playwright 测试✅ 运行bash e2e/docker-test.sh亲自验证一次零信任日志扫描 修改 Apple 协议代码时先阅读references/ApplePackage/中的 Swift 参考实现它是协议行为的事实来源。AssppWeb 的测试体系给新手的最大启示测试层级与安全架构一一对应——单元测试守住逻辑E2E 守住链路日志扫描守住零信任这条生命线。【免费下载链接】AssppWeb项目地址: https://gitcode.com/gh_mirrors/as/AssppWeb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考