是否有依赖于方法 TestNG 功能的隐式替代方案？（按相关顺序运行测试）答案

【问题标题】：Is there an implicit alternative to dependsOnMethods TestNG functionality? (running tests in dependent order)是否有依赖于方法 TestNG 功能的隐式替代方案？（按相关顺序运行测试）
【发布时间】：2013-10-10 10:22:21
【问题描述】：

让我们进行以下 TestNG 测试：

@Test 
public void Test1() {

}

@Test (dependsOnMethods={"Test1"}) 
public void Test2() {

}

@Test (dependsOnMethods={"Test2"}) 
public void Test3() {

}

Tests 用作功能性的端到端 webui 测试（使用 Selenium Webdriver）。每个测试方法都是长 e2e 场景中的一个步骤。

我们如何重构测试以使其更具可读性？最好的解决方案可能是删除注释中的所有这些“dependsOnMethods”参数，并隐式提供这个“dependsOnMethods”功能。问题是如何？按优先顺序排列的期望：

找到一个解决方案，让 TestNG 保持在船上
保留 TestNG，但涉及任何其他工具，例如容易吗？使用 groovy 而不是 java...我可以将 TestNG 组与 easyb 一起使用吗？是否有可能，不是 bdd 风格而是 'junit' 风格的easyb，比如：

鉴于“用户已登录并设置专家模式”，{
//... setup, a la @BeforeClass 
}

然后“用户可以启用bla bla bla”{
//... 
}

然后“用户可以检查便便便便”{
//... 
}

然后“用户保存更改”{
//... 
}

然后“用户还原更改”，{
// Tear Down, a la @AfterClass 
}

“刚开始在同一个 java 项目中用 groovy 编写其他测试类”有什么问题吗？

踢TestNG，但用什么？ TestNG 分组功能 - 是必需的。

一个疯狂的解决方案可能是 - 打破一切并搬到修昔底德。但就我而言，这不是一个选择。

PS 我知道依赖测试是一种“不好的做法”。但我相信“测试依赖项本身”也是自动化的一个好点......

【问题讨论】：

我不明白这个问题。拥有多个dependsOnMethods 有什么问题？我个人认为这是相当可读的

标签： java selenium groovy testng easyb

【解决方案1】：

是的.. 有一个替代使用取决于... 不要这样做！

正如我已经回答here...

这是一个糟糕的测试逻辑。作为一名经验丰富的专业软件测试工程师。我建议你立即远离你正在走的这条自动化道路。

良好的测试架构要求每个方法都是自给自足的，并且在继续之前不应依赖其他测试来完成。为什么？因为说测试 2 依赖于测试 1。说测试 1 失败..现在测试 2 将失败..最终，您将测试 1、2、3、4、5 测试失败，您甚至不知道是什么原因是。

先生，我对您的建议是创建自给自足、可维护且简短的测试。

这是一本很棒的读物，可以帮助您的努力：http://www.lw-tech.com/q1/ug_concepts.htm

【讨论】：

我完全理解你的想法。我有单独的套件，测试非常干净且自给自足。但我认为，在 QA 自动化的世界中有一个地方，“依赖”测试也可能存在。如果目标是测试“依赖”本身怎么办？从用户的角度来看，这就是“端到端功能测试”的意义所在。当例如用户在一个网页上启用和自定义某些服务，而不是转到另一个网页，并尝试自定义另一个服务，但由于在第一个“步骤”中建立的依赖关系而失败。这不是一个值得测试的好主意吗？
我明白一切都应该在一开始就在它的位置进行测试。并且这些服务应该在单元和集成级别上进行测试，用 stub/mock/fake 服务等进行相应的测试。但是如果在项目的当前阶段，开发人员中没有人会这样做呢？如果这些服务依赖于硬件，并且在硬件方面 - 而且，没有人会测试它们：) 我现在所拥有的 - 是模拟真实的用户场景，他可以做的所有依赖关系至少有一些自动化测试不会非常准确，但至少可以作为一个很好的烟雾 CI 套件。
不过，感谢您的意见。我知道这一点，但有时不能对这种情况下的主题给予足够的重视。我显然应该花更多时间来审查所有内容并尝试减少依赖项。

【解决方案2】：

保留 TestNG，但涉及任何其他工具，例如容易吗？使用 groovy 而不是 java...我可以将 TestNG 组与 easyb 一起使用吗？是吗可能，easyb 不是 bdd 风格，而是 'junit' 风格

这是我使用的选择。

你不会有像easyb这样的测试组（至少开箱即用），到目前为止我还没有找到任何方法来“注释”easyb/groovy“测试方法”。

但是，现在我有：

隐式依赖方法。尽管它们并不完全依赖 - 如果某些方法将被“禁用”，则仍将执行下一个方法。但是我的实际目标是可以实现的：由于测试文件是一个 groovy 脚本，所有的“测试方法”都将按照它们编写的顺序执行。一旦您需要禁用任何“测试方法”，您只需对其代码进行注释即可 - 这将禁用测试并在报告中将其显示为“待处理”。
测试方法具有可读的“sting”名称。

这是测试的外观：

beforeAllSetup()

before "each method setup", {
  //implementation
}
after "each method tear down", {
  //...
}

it "first test this", {
  //...
}

it "this will be shown as pending in the report", /*{
  //...
}*/

it "then test this", {
  //...
}

afterAllTearDown()

【讨论】：