从自定义框架迁移至Laravel，如何正确开展测试工作？

1. 用环境配置替代双文件夹维护 #

Laravel天生支持多环境配置，没必要再维护两个独立的代码文件夹：

• 只保留一套代码库，通过.env文件区分环境：
  • 生产环境（对应原来的main）：用.env配置生产数据库、域名appexample.com，关闭调试模式APP_DEBUG=false
  • 测试环境（对应原来的test）：新建.env.testing，配置测试专用数据库、域名test.appexample.com，开启调试APP_DEBUG=true
• 部署时给不同环境加载对应配置文件，不用重复维护代码逻辑。

2. 分支管理替代直接覆盖 #

原来的直接覆盖风险太高，结合Git分支管理更稳妥：

• 主分支main对应生产环境，只存放经过验证的稳定代码
• 专门创建test或develop分支，所有功能修改先在这个分支上开发、测试
• 测试通过后，通过合并请求将代码合并到main分支，再部署到生产环境
• 若需测试特定功能，还可创建临时feature分支，验证完成后再合并回主测试分支。

3. 自动化测试替代手动验证 #

Laravel自带PHPUnit和Pest支持，能大幅提升验证效率：

• 编写单元测试：针对核心逻辑（如模型方法、服务类功能），确保代码修改不破坏原有功能
• 编写功能测试：模拟用户操作（如表单提交、页面访问），验证完整业务流程的正确性
• 执行测试命令：运行php artisan test即可批量执行所有测试，比手动页面验证高效得多
• 测试环境可配置CI/CD，每次提交代码自动触发测试，提前发现问题。

4. 测试环境部署实操 #

若仍需保留test.appexample.com独立域名：

• 用Docker或虚拟主机搭建独立测试服务器，部署test分支代码并加载.env.testing配置
• 测试数据库可定期从生产环境同步（注意脱敏用户隐私数据），保证测试场景贴近真实情况
• 禁止直接修改测试环境代码，所有变更先在本地分支开发，提交后再部署到测试环境验证。

5. 过渡方案（兼容原操作习惯） #

若暂时不想彻底调整流程，可先采用过渡方案：

• 保留一套代码，复制两份分别部署到生产和测试服务器，对应各自域名
• 测试环境修改完成后，先在本地运行测试确认无误，再用rsync或专业部署工具同步到生产环境，避免直接复制文件夹导致的配置遗漏问题。

内容的提问来源于stack exchange，提问作者inGame