连续测试的代码结构
我正在建立一个CD管道。我正在计划它的自动化测试部分。我计划做UI、Web服务、安全性和性能测试。我有一个关于代码结构的问题。因此，我计划将测试与代码放在同一个repo中，然后对核心测试框架进行单独的repo。
回购产品
- 产品代码（项目）
- 集成测试（项目）
- 功能/e2e测试（项目）
- 用户界面测试（软件包）
- WebVC测试（软件包）
- 性能测试（套装）
- 秒。测试（包）
回购测试核心
- UI测试框架代码（项目）
有人看到这个结构有什么问题吗？还有其他想法吗？此外，我对集成测试和功能测试项目中的内容也有点模糊（例如，WebVC测试可以是两者的一部分）。验收测试去哪里（功能或集成）？如果有人能举出一些回购协议的例子或相关文章，那就太好了。
谢谢
共有1个答案
我觉得这种结构有点令人恼火。
从提出的结构中，我推断出你想构建自己的测试框架。这对我来说听起来很可疑，尤其是当你想写其中的4个的时候。
另一方面，您将它们都放在同一个存储库中，因此它们似乎密切相关。再说一遍：不一定是坏的/错的，但确实出乎意料。
因为除了结构之外，我在你的问题中找不到任何提示，这就给了我们一个很好的理由来拥有单独的存储库，所以我建议只使用一个存储库，假设你的“测试框架”只是测试主项目的实用工具。
基本规则是，一起更改的内容应该一起进行（在一个存储库中）。其他一切都让开发变得非常麻烦：更改A、安装、更改B、运行、调试、重复而不是更改、运行、调试、重复
既然你提到你还不完全清楚，什么会去哪里，我建议如下：
从一个项目开始。在该项目的测试目录中编写所有测试。观察你是否遇到问题。如果是这样，适应。你可能遇到的触发项目提取的事情：
- 测试运行得很慢，你想单独运行它们
- 测试需要一个已部署的应用程序，所以它们应该在构建和安装其他所有东西后运行
- 不同模块中的测试需要访问不应该存在于主项目中的代码，因此它可能最终会出现在支持测试的代码中
-
测试你的代码是非常重要的。 习惯于同时写测试用例和运行代码，现在被视为一个好的习惯。如果使用得当，这种方式将帮助你更加明确自己代码的功能，以及拥有更加可解耦的结构。 测试的通用规则： 测试单元应该集中于最小部分功能，并且证明它是正确的。 每个测试单元必须完全独立。他们都能够单独运行，也可以在测试套件中运行，而不用考虑被调用的顺序。 要想实现这个规则，测试单元应该加载最新的数据集，之后再做一些清理。
-
我们有一个Spring批量应用程序。除了运行应用程序的能力之外，我们还拥有一些轻量级测试类，这些类允许我们单独运行每个作业，并在作业完成后执行断言。 这对于在本地运行测试很好。但是，对于定义测试在持续集成环境（如TeamCity）中运行的最佳实践，有没有人能给出建议。 对于使用持续集成测试Spring Integration应用程序，也有一个类似的问题。
-
问题内容： 我刚遇到以下问题。 这是我第一次看到这个。它是如何工作的？ 问题答案： 它只是编写两个不同的代码块以隐藏局部变量。 从问题“ Java中的匿名代码块”的答案： 块限制变量范围。 但是，实际上，如果您发现自己使用了这样的代码块，则可能是您要将其重构为方法的信号。
-
对代码基址的每一次更改都运行自动化测试 准备好开始在您的开发人员测试活动中大获全胜吗？在本期的 让开发自动化 中，开发自动化专家 Paul Duvall 介绍了几种自动化的开发人员测试，每一次改变源代码都能够运行这些测试。Paul 提供了 Selenium、DbUnit 和 JUnitPerf 测试的例子，即，如果经常 运行这些测试可以帮助您尽早发现应用程序的问题。 在像 Eclipse 那样的
-
问题内容： 我想替换String输入中的一些字符串： 如您所见，这种方法不是最佳方法，因为每次我必须搜索要替换的部分时，等等，并且字符串是不可变的…而且输入很大，这意味着要考虑一些性能问题。 有没有更好的方法来减少此代码的复杂性？ 问题答案： 尽管与相比是一个巨大的改进，但它 离 优化还差 很远 。 问题在于，如果替换的长度与可替换部分的长度不同（适用于我们的情况），则可能必须分配更大的内部数组，