VibeCoding 实战：用 Qoder 从零开发 Java Spring Boot WMS 系统（十）
第9章 测试修复与部署：质量收尾并上线
本章目标：用 Qoder 完成三件收尾工作——① 让 AI 为核心业务写自动化测试（尤其是防超卖、事务回滚这种"最容易出事"的地方）；② 用 AI 定位并修复测试/联调发现的 Bug；③ 用 Docker Compose 把系统部署起来，并做上线前的安全检查。本章结束，你会得到一个可对外访问、且有测试兜底的 WMS。
学习目标
- 会让 AI 为关键业务生成 JUnit 测试用例并跑通
- 掌握"把报错/失败用例丢给 AI 修"的调试闭环
- 能用 Docker Compose 一键部署 前端+后端+MySQL
- 建立上线前的安全检查清单意识
9.1 让 AI 写测试：把"最怕出错的地方"钉死
VibeCoding 里测试尤为重要——代码是 AI 写的，你不可能逐行读，用测试用例锁住关键行为，就成了你敢不敢上线的信心来源。优先测那些"业务规则硬约束"：防超卖、状态机非法流转、事务回滚。
提示词
为 WMS 后端补充 JUnit 5 + Spring Boot Test 自动化测试，重点覆盖以下"高风险业务规则"，
每条都要有正向和反向用例：
1. 出库防超卖：库存100时，
- 出库30 成功、库存变70
- 出库200 失败、抛业务异常、库存保持100
2. 入库/出库事务原子性：模拟执行过程中某一步失败，断言库存与流水都回滚
3. 入库状态机：对 DRAFT 单直接调用"执行入库"，断言被拒绝
4. 单号唯一：同一天连续创建两张入库单，断言尾号递增不重复
5. 商品编码唯一：重复编码新增断言失败
6. 盘点盘亏超量：实盘导致库存变负时断言确认被拒绝
测试用 H2 内存库或独立的测试库（不要污染开发数据），给出必要的测试数据准备方式。
写完运行 mvnw test，把测试结果贴给我；失败用例先分析原因。
预期结果
src/test下生成测试类，mvnw test大部分通过- 个别失败很正常——这正是要处理的 Bug 线索
注意事项
- ⚠️ 别追求 100% 覆盖率。教学阶段只测"会出事的核心规则"，这比给一堆 getter/setter 写测试有价值得多。
- 💡 测试环境数据库：让 AI 用
application-test.yml+ H2/Testcontainers 隔离数据，避免测试把开发库的库存改乱。
9.2 Bug 修复闭环：把失败"原样"交给 AI
测试或联调发现 Bug 时，不要自己乱改。用规范的"报障"方式让 AI 定位修复：
提示词（报障模板）
一个用例失败了，请帮我定位并修复：
【现象】测试"出库防超卖-出库200应失败"实际却成功了，库存变成了 -100
【相关代码】#引用 OutboundService.execute 方法
【报错/断言信息】
<把失败堆栈或断言差异原样粘贴>
请先分析根因（是不是又用成了"先查后扣"？条件 UPDATE 的影响行数有没有正确判断？），
说明你打算怎么改，改完重新运行该测试确认通过。不要改动无关代码。
好的报障 = 三要素
- 现象：期望什么、实际什么
- 定位线索：引用相关代码/日志/堆栈
- 约束：只改这个问题、别顺手重构一堆（防止 AI "过度热心想改很多不该改的"）
💡 "不要改动无关代码"这句话，是控制 AI 修 Bug 时"越修越乱"的关键。AI 有时会把一个小问题升级成大重构，务必框住范围。
9.3 上线前的安全与配置检查
第4章留了两个"待办"，现在必须补上（AI 生成的代码常有"图省事"的默认值）。
提示词
部署前帮我做一次安全与配置整改：
1. JWT secret、数据库密码不要硬编码在 application.yml，改为从环境变量读取
（DB_PASSWORD、JWT_SECRET），并说明本地/容器分别如何注入
2. 生产 profile（application-prod.yml）：关闭 sql 日志打印、关闭 devtools、
错误响应不泄漏堆栈（全局异常返回统一 Result，不暴露内部信息）
3. 后端启动时不要打印用户密码等敏感信息
4. 检查并列出你认为本项目还有哪些上线前应关注的安全点（如接口鉴权是否有遗漏、
文件上传等），逐条说明建议
把配置改动落实到文件，并告诉我改了哪些。
注意事项
- ⚠️
spring.profiles.active别在代码里写死 prod，用启动参数或环境变量切换，方便本地开发。 - 💡 这一步让 AI 主动"提安全建议"，是在训练它当你的"技术负责人"——多问它"你觉得还差什么"，往往能发现自己忽略的点。
9.4 用 Docker Compose 一键部署
把 前端、后端、MySQL 打包成可一键启动的服务。这是 VibeCoding 的"高光时刻"：这些 Docker 文件你几乎不用自己写。
提示词
为项目容器化部署，在工作区生成部署文件：
1. 后端 wms-server/Dockerfile：多阶段构建（maven 构建 → jre 运行），
JVM 参数留出，暴露 8080，从环境变量读 DB_PASSWORD/JWT_SECRET
2. 前端 wms-web/Dockerfile：node 构建产物 → nginx 托管静态文件，
nginx 配置里把 /api 反向代理到后端服务（container 名 wms-server:8080）
3. 根目录 docker-compose.yml：三个服务 mysql(挂载数据卷+初始化 db/schema.sql,db/data.sql)、
wms-server(依赖 mysql，注入环境变量)、wms-web(依赖 server，暴露 80)
4. .env.example 列出需要设置的变量（DB 密码、JWT secret 等）
5. 写一份 README-部署.md：如何改 .env、docker compose up -d 启动、访问地址、如何看日志
生成后，说明本机需要装 Docker，并给出启动与验证步骤。
部署验证步骤（本机装了 Docker Desktop 后）
cd 你的工作区
copy .env.example .env # 然后编辑 .env 填入密码/secret
docker compose up -d --build
docker compose ps # 三个服务应为 running/healthy
浏览器访问 http://localhost（前端经 nginx），用 admin 登录后完整点一遍入库→库存→出库，确认线上环境和本地开发表现一致。
注意事项
- ⚠️ 数据库初始化脚本要在容器首启时执行：把
db/schema.sql、db/data.sql挂到 MySQL 容器的/docker-entrypoint-initdb.d/。若没建表就启动后端会连不上表——这是最常见的部署坑。 - ⚠️ 前端 nginx 反代
/api的目标要用 compose 服务名（如wms-server），不是localhost。容器之间用服务名互联，写成 localhost 会 502。 - 💡 若你本机暂时没装 Docker，也可先用"本地跑后端 + 本地跑前端
npm run build后npm run preview"的方式演示，Docker 部署留到有环境时再做。
9.5 回到最初：验收 M1
还记得第2章那句 M1 验收标准吗？现在逐条对照，做一次"真人验收"：
提示词
这是我们第2章定的 M1 验收标准：
<粘贴第2章那句验收标准，例如："能登录，录入商品和储位，创建入库单审核执行后库存增加，
再创建出库单拣货后库存减少，每步都能在流水查到">
请对照当前【已部署/已运行】的系统，逐条走一遍并给出证据（接口响应或页面截图说明），
确认每一条是否满足。如果有不满足的，指出是哪个模块的问题并给出修复建议。
这一步把"需求 → 设计 → 实现 → 验收"整个闭环合上了——这正是企业研发里最看重的"可追溯性"。
本章检查清单
- [ ] 核心业务规则有 JUnit 测试，
mvnw test通过 - [ ] 至少经历一次"报障→AI 定位→修复→重测通过"的闭环
- [ ] 密码/secret 改为环境变量，生产 profile 配置就绪
- [ ]
docker compose up能拉起 前端+后端+MySQL - [ ] 线上环境完整点通"登录→基础数据→入库→库存→出库→流水"
- [ ] M1 验收标准逐条核对通过
- [ ] 已提交 Git
部署完成，进入 第10章 总结与进阶。
常见问题
Q：Docker 构建后端时卡在下载 maven 依赖。
A：容器内没有你本机的阿里云镜像配置。让 AI 在 Dockerfile 构建阶段加 -s 指定 settings.xml 或直接用 aliyun 镜像仓库地址。
Q：docker compose up 后端起不来，日志报连不上数据库。
A：多是启动顺序/健康检查问题。让 AI 给 wms-server 加 depends_on: mysql: condition: service_healthy，并给 mysql 配 healthcheck。数据库初始化也需要时间。
Q：前端页面能开，但接口全 502/跨域。
A：确认是走 nginx 反代 /api 到后端服务名，而不是前端里写死后端 localhost:8080。生产环境前端已构建为静态文件，VITE 代理不再生效，必须靠 nginx 反代。