答案。

合理的版本控制和自动测试的集成对于确保测试与项目的当前状态相符是至关重要的。

问题历史

自动测试最初常常是与主项目分开进行的，这导致了不兼容性和维护问题。多个分支的发展、频繁的软件和测试发布——产生了一个共同的版本控制系统的需求。

问题

没有版本控制和一致集成时会出现：

• 在已更改的软件上运行过时的测试
• 在推出新的功能时，未考虑到测试更改而“破坏”测试
• CI/CD 失败

解决方案

现代方法：

• 测试存储在共享的版本控制系统中（通常是 git）
• 测试分支与软件开发分支绑定：在功能分支中，测试和代码一起进行
• 通过 pull request 进行自动检查/构建
• 对测试和代码的更改进行审查和协商

# 一般方法：
git checkout -b feature/new_login
# 功能和测试一起开发和测试
# 审查后一起合并主分支

关键特性：

• 代码和测试更改的一致性（无失同步）
• 方便的回滚和版本对比（通过 git history）
• 团队合作和自动测试的代码审查能力

有陷阱的问题。

可以将测试存储在一个与项目代码分开的仓库中吗？

可以，但那样更难以保持测试的时效性，需要手动同步，存在在发布或修复bug时“忘记”更新某些东西的风险。

在创建 PR 时，测试是否应该立即覆盖所有新功能？

理想情况下——是的，实际上通常在第一个 PR 中只覆盖 MVP/主要场景，复杂的案例作为单独任务处理。关键功能应立即覆盖。

可以只回滚测试更改而不回滚代码吗？

如果测试和代码一起在同一个分支中——可以回滚修订。但最好避免没有代码的“回滚”测试：这样会降低检查质量。

常见错误和反模式

• 测试不在 git 中存储，而是在文件系统中
• 在没有明确与项目的联系的情况下在单独的仓库中管理测试
• 在代码之外（事后）合并测试，而不是与代码同时进行

生活中的例子

消极案例

一个有单独自动测试仓库的项目。在发布后，程序员“忘记”更新测试——测试失败，过时的检查通过，bug 在生产环境中被捕获。

优点：

• 程序员可以独立于 QA 工作

缺点：

• 在同步中浪费时间，存在“过时”测试

积极案例

测试和项目代码在同一 git 分支中进行：每当有新的 pull request 时，确保更新添加代码的自动测试。所有更改都经过代码审查和自动检查。

优点：

• 快速反馈测试质量
• 更改的一致性

缺点：

• 需要诚实的团队合作和审查纪律