如何将“小、原子、自主”规则应用于复杂工程

Question

我受雇于一家公司，在那里我是团队中唯一的QA工程师。我的目标之一是使用Selenium实现UI测试的自动化。我正在做的这个项目，是一个复杂的形式，每个步骤都是相互关联的。我的意思是，如果没有完成第一步，就不可能通过表格的第二步。假设表单有12页。

我已经自动化了这个项目，但是我想让我的代码变得更好，并完成一个广为人知的模式和良好实践。其中一个流行的做法是保持测试“小，原子，自主”。我读了很多关于它的书，但是我不知道如何将它实现到我的项目中。我的测试不能是自主的，因为技术上是不可能的，我想。我的问题是:有人在像我这样的项目中有经验吗?你是如何完成上面描述的规则的？在每一种情况下，我应该遵守这些规则、良好做法和模式吗？

Answer 1

“小的、原子的、自主的”更适合于单元测试，而不是像您正在编写的UI/端到端测试。

当然，你应该试着使你的测试是小的和自主的。但是，您经常不能这样做，因为您的目标不是测试项目的一小部分，而是完成用户与系统的交互，通常是几个变体，这取决于业务逻辑。

例如，我的一个测试创建了多个版本的产品，然后以具有不同安全设置的几个不同用户登录到系统，检查在十几个页面中是否存在所创建的产品，并根据业务规则显示/启用/禁用按钮，然后删除产品的某些功能(根据规则)，然后再次检查相同的页面。

整个测试运行时间超过15分钟，其速度与和browser可以加载网页一样快。对于许多纯粹主义者来说，这并不是“小”测试--但这只是一个测试，检查同一产品的不同版本的业务逻辑，以及几个网页如何处理它们。功能实现为一个特性(与许多现有页面一起使用)。

帮助这个测试易于管理的是好的老式对象设计:对所有页面使用pageobject，以及使用数据驱动的设计，其中测试数据定义了产品的不同变体，测试解释了数据，所以数据的定义(定义中只有几行“小而自主”)准确地描述了测试的每一个步骤中将发生的事情。

您可以在更复杂之前使用“自治”运行更简单(更快)的测试:在上面的示例中，在创建整个批处理和测试所有用户和页面之前创建产品的单个变体。但是在e2e测试中，您的测试永远不会是小的和自主的，除非您可以登录检查之类的琐碎情况。

Answer 2

我订阅的第一-快速，独立，可重复，自我验证，及时.测试需要尽可能快地运行(没有隐含的等待或休眠)，以相同的预期结果单独运行，可以与自己同时运行(部署之前和之后)，以断言结束(我还遵循安排、行为、断言)，并作为CI的一部分运行，具有可靠和易于解析的结果。

您希望尽可能简单地测试所有内容，但通常一个函数依赖于另一个函数。对于我们的例子，我们需要登录，然后更新我们的配置文件。因此，如果不首先点击“登录”页面，我们就无法测试“配置文件”页面。好吧，我们已经为登录进行了一个小型的、愉快的路径测试，看起来可能是：

[Test]
public void Login_HappyPath()
{
    // Arrange: Get necessary values
    User user = User.GetUser("admin");
    // Act: Login using valid credentails
    App.LoginPage.LoginAs(user);
    // Assert: Login was successful
    Assert.IsTrue(App.GlobalToolbar.UserProfileImage.Displayed);
}

对于每个需要先登录的测试，我们只需调用登录方法，然后继续生活。如果登录没有任何原因，那么我们将永远无法测试‘配置文件’页面，因为测试(S)可能会抛出一个异常试图到达那里。

使用CRUD (创建、读取、更新、删除)操作，事情开始变得更加复杂。通过阅读，我们需要一份记录作为先决条件。有很多方法可以获得测试记录。您可以在测试的“排列”部分中添加数据，也可以在数据库中有特定的只读测试记录。选择还在继续。

[Test]
public void Read_HappyPath()
{
    // Arrange: Get the ID for the test record
    string recordId = TestUtils.GetTestRecord("read_happypath");
    // Act: Request the record by ID
    JObject recordJsonObject = App.RecordsPage.RequestById(recordId);
    // Assert: The record 
    Assert.AreEqual(recordId, recordJsonObject["id"].ToString()); 
}

外卖:首先，尽可能小地测试所有东西(“单元”测试)。然后开始将常见方法链接到其他(“集成”)测试中。当“集成”测试失败时，不要感到惊讶，因为您可能能够将其追溯到“单元”测试。在测试设计中一定要小心，这样一个测试就可以自己运行了。注意:我在这里松散地使用“单元”和“集成”这两个术语。