我正在重构我们的测试套件以利用页面对象模式。我缺少如何构造实际的测试。

让我说我要测试StackOverflow的发布和删除。一旦场景如下所示：

场景1：发布测试


登录
创建帖子
验证帖子是否可见

场景2：删除测试


登录
创建帖子
删除帖子
验证帖子已消失

我的问题：

自动测试的一般准则似乎要求断言的项目越少越好。但是，很明显，方案1和方案2几乎相同，并且违反了DRY。另一方面，如果将这两者结合起来，将很难理解故障，可能难以理解故障的长度以及影响的可读性和易于维护性。鉴于在实际测试中，可能存在许多场景中包含许多重复步骤，因此构造它们的最佳方法是什么？

编辑：

这里的博客文章描述了一个非常相似的场景和潜在的解决方案。简而言之，建议的解决方案是创建PostTest类，然后从中继承RemoveTest类。这符合DRY，但我仍然对此方法表示怀疑。如果发布失败，则发布测试和删除测试都将失败并产生嘈杂的输出（特别是如果测试以随机顺序执行）。我仍然不确定这是否比整体的“发布并删除”测试更好。

#1 楼

我自己使用页面对象模式。它解决了两个主要问题：


在一个地方定义查找器
用英语单词来命名查找器

好东西。但这并没有解决如何组合在多个地方使用的一系列步骤的问题。要做到这一点，您可以使用所使用语言的功能/过程/方法。概括地说，您有两种选择来进行这种设置-使用应用程序屏幕，或使用后端调用来创建所需的对象。

#2 楼

就像Michael所说的那样，Page对象模式使查找器更易于使用。
我试图维持一种模式，即只验证一个东西或可能一个屏幕的测试。测试，您将测试有关该帖子可见的所有内容。在第二项测试中，创建帖子步骤只是设置步骤，因此您要删除帖子，这就是您要进行验证的步骤。根据有意义的内容，我只会在该帖子上使用一个断言来验证它是否已成功发布，而不会在可见性方面进行断言。

评论

谢谢罗伊。我想我想了解的是将方案1和方案2组合到一个测试中是否有优势。如果方案1（发布）失败，则没有方案2（删除）可以提供的有用信息。

–EightyEight
16年1月25日，下午2:35

#3 楼

以我的经验，正如您正确提到的那样，如果创建失败，甚至无法测试删除，因此实际上您只有一个测试，带有两个单独的测试条件。

到目前为止，对于每个单独的场景，我只有一项测试具有多种测试条件。测试从准备系统到特定状态开始，这与其他测试无关。然后，所有子测试都将期望这种情况，或者先前步骤的成功。我发现，与单元测试不同，集成/系统测试很难彼此独立。

可重用的代码进入pageobject或helper类，并且几乎没有重复，因此到目前为止，我的方法对我们来说还行。