testing - 源代码存储库或单独存储库中的自动化测试套件？

Question

我认为最佳做法是将测试套件维护在与源代码相同的存储库中，以使测试与代码更改保持同步。但是，如果基础架构或编码策略不允许将不相关的文件添加到源代码中怎么办？是否有更好的方法通过为测试套件提供单独的 repo 协议(protocol)来保持代码和测试之间的同步？提前致谢

Answer 1

我认为这取决于您的目标/团队和项目。我在这两种模型中都工作过，并且发现了使用这两种模型的优点和缺点。

同一存储库中的自动化:

优点:

• 您可以共享代码和元素定位器(例如与 Espresso)，因此易于维护
• 开发人员很容易帮助维护(如果他们想要/必须这样做)
• 开发人员可以更清楚地进行代码审查和检查 PR
• 在开发人员和 QA 之间共享有关代码和测试的知识
• 开发人员可能会不小心破坏自动化代码(但如果 qas 正在进行审查，这种情况应该很少见)
• 测试自动化将使用与开发代码相同的语言

缺点:

• 您可以共享代码，因此如果您的函数存在错误并且您在测试中使用相同的函数，那么您的测试也会有错误
• QA 可能会意外破坏开发代码(但如果开发人员正在进行审查，这种情况应该很少见)
• 项目之间的 E2E 测试没有意义，因为测试被放置在一个项目的 repo 中并与其他项目集成
• 项目之间的 E2E 测试将需要模拟以测试其他产品/项目的场景，否则，如上所述，将测试项目放在项目仓库中是没有意义的
• 不能在项目之间共享代码/函数，因为测试项目与不同存储库中的其他测试项目共享函数会造成混淆(除非您使用这些共享函数创建测试存储库)+您可能有测试自动化在 javascript 中为 Web 项目和移动项目编码，您将拥有与开发团队相同的代码，这可能与 Web 不同，例如 kotlin 或 swift

独立存储库中的自动化:

优点:

• 您可以在测试项目之间共享代码
• 您将降低维护成本，因为项目可以在不同平台项目之间共享
• 测试自动化可以使用编写代码的团队更熟悉的语言，或者使用在不同平台的项目之间维护代码时更有优势的语言

缺点:

• 对开发人员来说不是真正可见的，因为他们可能不会跟进
• 您可以在不模拟它们的情况下正确创建涉及不同平台上所有项目的 E2E 测试
• 开发人员遵循和维护测试自动化的动力不是很大

无论如何，我可能遗漏了一些东西，但我只是试着记住所有的关键点。最后，团队应该一起决定这一点，因为这又取决于开发人员是否也要维护测试，以及您是否要在需要或不需要模拟其他项目的情况下执行端到端测试