为什么单个命令(ant/maven)总是比驱动测试套件(TestNG)更受欢迎?
Why single command(ant/maven) is always preferred to drive Test suite (TestNG)?
我们的企业产品有一个 TestNG 测试套件。它是 8 多年前开发的,不支持单个 ant 命令 运行 所有测试。因此,我们需要一次 运行 单个测试套件。
现在,我更改了测试套件的结构,并将 testng.5.4-jdk.jar
更新为 testng.6.8.jar。作为更改单个 jar 的企业应用程序也很重要,因为我们需要确保所有其他组件都应该适用于此更新。
我们计划为每个单独的套件设置不同的 Jenkins 作业(60 个不同的作业,因为每个测试套件由不同的团队维护)。
所以,我需要管理的答案:
- 为什么驱动测试套件的单个命令是个好主意?
- 如何维护 60 个不同的 Jenkins Jobs 不是一个好主意?
- 基本上旧的 testng.5.4 jar 没有 ITestContext class,所以这对我们将来有什么帮助,一些代码片段将不胜感激。
此类问题的答案只能基于意见。
所以:
- 对 运行 所有测试的单个命令对开发人员非常有帮助。在 commit/push 之前,他们可以通过单个命令验证产品状态(如果您的测试良好)。另一方面,如果有这么多套件 (60),它们可能会花费很多时间来执行,最终开发人员可能会开始完全跳过测试。就个人而言,我更喜欢对每个模块进行 运行 测试的命令(这对于 maven 来说非常容易:mvn test 或 mvn verify用于集成测试)。
- 这里的主要问题可能是团队沟通。如果一个团队只维护一个套件,他们会知道对他们套件的修复是否没有破坏其他套件吗?无论如何,我建议保留单独的测试套件 运行 作业和一体式作业作为冒烟测试。
- 只需阅读 api 文档。似乎可以帮助获取测试的元信息。
此类问题的答案只能基于意见。
所以:
1 : Gradle、Maven 和 Ant 自动处理所有依赖项下载。您希望使用它来启动您的测试套件,因为您不想将所有这些 .jar 工件存储在您的本地 Git 存储库中。那会真的很乱。如果您需要做类似的事情,您可以使用 Sync
指令同步 Gradle 中下载的库。然后,您可以受益于将所有 .jar 库都放在项目的本地,而不会污染源代码控制存储库,并且仍然可以通过将这些 .jar 文件包含在测试的 -classpath
参数中来启动独立命令行 运行.
2 : Jenkins 可以轻松处理 100 多个作业。这没什么不寻常的,我会推荐它。
3:TestNG ITestContext 主要在 @Before
和 @After
配置方法中真正帮助您,以便您可以从常规 @Test
块之外访问测试上下文,并且其中包括 DataProvider 方法签名。
@BeforeMethod
public void beforeMethod(ITestContext iTestContext){
String testName = iTestContext().getName();
有时能够查看一个 jenkins 作业的状态以查看是否所有测试都已通过会很有帮助。 Dashboards 插件是一个很好的例子,您的视觉 space 有限并且希望能够一目了然地查看整个系统的状态(对于喜欢 public 有更新的地方的巨型监视器的经理/ 状态消息)。
请记住,每个 jenkins 作业都会将整个存储库下载到其工作中space。因此,如果您有 60 个不同的 jenkins 作业,那么整个工作将有 60 个不同的副本space,这可能会使您的 jenkins 服务器混乱并在您的构建节点上浪费 space。您可以通过将单元测试信息放入单元测试的专用存储库来避免这个问题。但是随后您需要将编译后的工件 URL 传递到测试工作 space 中,以便单元测试知道要 运行 反对什么。
总结一下我得到的是:-
- 存储:- 如果我使用 60 个不同的作业,它将克隆 60 个 git 存储库、项目、测试输出。
- 詹金斯管理:-
- 管理单个作业总比管理多个作业好,因为我还必须连接其他测试套件。
- 此外,我们应该必须增加从机执行器的数量(基础设施成本)到 运行 一次测试这么多。
- 有很多机器需要更多维护(安装了插件、工具和依赖软件,需要及时更新)
- 单一仪表板:-从管理的角度来看,最好查看中央全局仪表板。
- 太多通知:- 太多电子邮件肯定会产生垃圾邮件,而不是一封带有 link 到 TestNG 仪表板的邮件总是好的。
- ITestContext :- 这对驱动您的测试非常有帮助,如下所示
ITestContext 的最大用处是您可以迭代测试标签和 运行 多个 tests/suites 并且可以将 HashMap 作为参数传递以驱动您的测试(数据驱动测试)
大多数时候,如果您有一些网络应用程序,功能主义者是相同的,但您的操作可能会因输入数据而异。因此,您可以拥有一些可以通过 TestNG xml 文件重新利用的 java 代码。
<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<suite name="Some Tests" verbose="0">
<test name="First Test">
<parameter name="testConfigFile"
value="TestConfig.xml" />
<parameter name="testConfigFile"
value="TestConfig1.xml" />
<parameter "as many params "..... />
<classes>
<class name="com.testframework.FirstTests">
</class>
<class name="com.testframework.FoobarTests">
</class>
</classes>
</test>
<test name="Second Test">
<parameter name="testConfigFile"
value="SecondTestConfig.xml" />
<classes>
<class name="com.testframework.SecondTests">
</class>
</classes>
</test>
</suite>
您可以通过此功能获取所有测试数据
/**
* This method parse input TestNG xml file and based on each <test></test>
* input tags and iterate over all tests.
* @param context
* @return HashMap of all input tests params required for the tests.
*/
@DataProvider(name = "DataFile")
public Object[][] testdata(ITestContext context) {
Map<String, String> parameters = (((ITestContext)context).getCurrentXmlTest())
.getAllParameters();
return new Object[][] { { parameters } };
}
最后,您的测试可以不断迭代直到测试完成
@Test(dataProvider="DataFile")
public void testImplementation(Map parameter) {
// here your unit test will go
}
我们的企业产品有一个 TestNG 测试套件。它是 8 多年前开发的,不支持单个 ant 命令 运行 所有测试。因此,我们需要一次 运行 单个测试套件。
现在,我更改了测试套件的结构,并将 testng.5.4-jdk.jar
更新为 testng.6.8.jar。作为更改单个 jar 的企业应用程序也很重要,因为我们需要确保所有其他组件都应该适用于此更新。
我们计划为每个单独的套件设置不同的 Jenkins 作业(60 个不同的作业,因为每个测试套件由不同的团队维护)。
所以,我需要管理的答案:
- 为什么驱动测试套件的单个命令是个好主意?
- 如何维护 60 个不同的 Jenkins Jobs 不是一个好主意?
- 基本上旧的 testng.5.4 jar 没有 ITestContext class,所以这对我们将来有什么帮助,一些代码片段将不胜感激。
此类问题的答案只能基于意见。
所以:
- 对 运行 所有测试的单个命令对开发人员非常有帮助。在 commit/push 之前,他们可以通过单个命令验证产品状态(如果您的测试良好)。另一方面,如果有这么多套件 (60),它们可能会花费很多时间来执行,最终开发人员可能会开始完全跳过测试。就个人而言,我更喜欢对每个模块进行 运行 测试的命令(这对于 maven 来说非常容易:mvn test 或 mvn verify用于集成测试)。
- 这里的主要问题可能是团队沟通。如果一个团队只维护一个套件,他们会知道对他们套件的修复是否没有破坏其他套件吗?无论如何,我建议保留单独的测试套件 运行 作业和一体式作业作为冒烟测试。
- 只需阅读 api 文档。似乎可以帮助获取测试的元信息。
此类问题的答案只能基于意见。
所以:
1 : Gradle、Maven 和 Ant 自动处理所有依赖项下载。您希望使用它来启动您的测试套件,因为您不想将所有这些 .jar 工件存储在您的本地 Git 存储库中。那会真的很乱。如果您需要做类似的事情,您可以使用 Sync
指令同步 Gradle 中下载的库。然后,您可以受益于将所有 .jar 库都放在项目的本地,而不会污染源代码控制存储库,并且仍然可以通过将这些 .jar 文件包含在测试的 -classpath
参数中来启动独立命令行 运行.
2 : Jenkins 可以轻松处理 100 多个作业。这没什么不寻常的,我会推荐它。
3:TestNG ITestContext 主要在 @Before
和 @After
配置方法中真正帮助您,以便您可以从常规 @Test
块之外访问测试上下文,并且其中包括 DataProvider 方法签名。
@BeforeMethod
public void beforeMethod(ITestContext iTestContext){
String testName = iTestContext().getName();
有时能够查看一个 jenkins 作业的状态以查看是否所有测试都已通过会很有帮助。 Dashboards 插件是一个很好的例子,您的视觉 space 有限并且希望能够一目了然地查看整个系统的状态(对于喜欢 public 有更新的地方的巨型监视器的经理/ 状态消息)。
请记住,每个 jenkins 作业都会将整个存储库下载到其工作中space。因此,如果您有 60 个不同的 jenkins 作业,那么整个工作将有 60 个不同的副本space,这可能会使您的 jenkins 服务器混乱并在您的构建节点上浪费 space。您可以通过将单元测试信息放入单元测试的专用存储库来避免这个问题。但是随后您需要将编译后的工件 URL 传递到测试工作 space 中,以便单元测试知道要 运行 反对什么。
总结一下我得到的是:-
- 存储:- 如果我使用 60 个不同的作业,它将克隆 60 个 git 存储库、项目、测试输出。
- 詹金斯管理:-
- 管理单个作业总比管理多个作业好,因为我还必须连接其他测试套件。
- 此外,我们应该必须增加从机执行器的数量(基础设施成本)到 运行 一次测试这么多。
- 有很多机器需要更多维护(安装了插件、工具和依赖软件,需要及时更新)
- 单一仪表板:-从管理的角度来看,最好查看中央全局仪表板。
- 太多通知:- 太多电子邮件肯定会产生垃圾邮件,而不是一封带有 link 到 TestNG 仪表板的邮件总是好的。
- ITestContext :- 这对驱动您的测试非常有帮助,如下所示
ITestContext 的最大用处是您可以迭代测试标签和 运行 多个 tests/suites 并且可以将 HashMap 作为参数传递以驱动您的测试(数据驱动测试)
大多数时候,如果您有一些网络应用程序,功能主义者是相同的,但您的操作可能会因输入数据而异。因此,您可以拥有一些可以通过 TestNG xml 文件重新利用的 java 代码。
<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<suite name="Some Tests" verbose="0">
<test name="First Test">
<parameter name="testConfigFile"
value="TestConfig.xml" />
<parameter name="testConfigFile"
value="TestConfig1.xml" />
<parameter "as many params "..... />
<classes>
<class name="com.testframework.FirstTests">
</class>
<class name="com.testframework.FoobarTests">
</class>
</classes>
</test>
<test name="Second Test">
<parameter name="testConfigFile"
value="SecondTestConfig.xml" />
<classes>
<class name="com.testframework.SecondTests">
</class>
</classes>
</test>
</suite>
您可以通过此功能获取所有测试数据
/**
* This method parse input TestNG xml file and based on each <test></test>
* input tags and iterate over all tests.
* @param context
* @return HashMap of all input tests params required for the tests.
*/
@DataProvider(name = "DataFile")
public Object[][] testdata(ITestContext context) {
Map<String, String> parameters = (((ITestContext)context).getCurrentXmlTest())
.getAllParameters();
return new Object[][] { { parameters } };
}
最后,您的测试可以不断迭代直到测试完成
@Test(dataProvider="DataFile")
public void testImplementation(Map parameter) {
// here your unit test will go
}