测试关注点泄漏

测试关注点泄漏是指在强制执行测试关注点分离时，规范细节被推送到可执行代码中，或者（反过来）实现细节被推送到故事中。

通常，xUnit 测试不会强制执行关注点分离。

然而，使用 Hitchstory、Robot 或 Cucumber 等工具编写的 storytest 通常会出现测试关注点泄漏。

向下关注点泄漏

向下关注点泄漏是最常见的关注点泄漏形式 - 行为规范细节从规范语言向下推送到执行测试的代码中。

例如，这个故事（摘自 Cucumber 教程）就体现了向下关注点泄漏。

  Scenario: Create a new person
    Given API: I create a new person
    Then API: I check that POST call body is "OK"
    And API: I check that POST call status code is 200

这里如何创建新人员完全没有指定。

不幸的是，Cucumber 故事通常存在这个问题，因为该语言的表达能力不足，无法表示复杂的规范。

用于执行此故事的步骤代码对这些事情很精确，但它将被推送到用于执行这些步骤的步骤代码中。

没有向下关注点泄漏的等效 hitchstory 将包含更多细节。

Create a new person:
  steps:
  - Call api:
       request:
         method: POST
         path: /person/new
       request content: |-
         {
            "name": "Tom Jones",
            "dob": "1990-12-25",
            "type": "employee"
         }
       response:
         code: 200
       response content: |-
         {
           "status": 200
         }

这个故事仍然缺少一些可能对规范至关重要的细节（例如，身份验证、请求标头），但添加这些细节很简单 - StrictYAML 足够灵活，可以允许对数据进行复杂的表示。

向上关注点泄漏

向上关注点泄漏是指将与用户行为无关的实现细节“泄漏”到故事中。

这个例子来自 github 上的一个真实故事，但被翻译成了 hitchstory。

Use select and deselect all buttons:
  based on: Logged in as teacher1
  steps:
  - Follow: Course 1
  - Follow: Participants
  - Click: Select all
  - Field with:
      xpath: //tbody//tr[1]//input[@class='usercheckbox']
      should be: 1
  - Field with:
       xpath: //tbody//tr[2]//input[@class='usercheckbox']
       should be: 1

这里，Xpath 选择器“污染”了故事。

为了减轻这个问题，可以使用某种标签-xpath 转换层，或者使用更容易阅读的选择器。

为什么关心测试关注点泄漏？

测试关注点泄漏可能不是任何项目的生存问题。如果一个项目经过充分测试，但测试难以理解，它仍然是经过充分测试的。

尽管如此，保持严格的测试关注点分离仍然有益。如果向下泄漏最小化了，

执行故事的引擎代码变得更加通用和可重用。
规范变得更加易于访问。这使得故事成为 BDD-ATDD 联系的一部分 - 也就是说，它们适合与更广泛的利益相关者进行关于软件行为的高级讨论。
它允许你构建三元组功能。