unit-testing - BDD 场景何时变得过于具体？

Question

在对 TDD 和 BDD 进行了非常鼓舞人心的培训后，我尝试使用 MSTest 实现该方法。和 Specflow .但我有一个问题，我坚持:

我编写了验收测试来验证我们正在开发的子系统。
我们的系统有点分散:

有第 3 方电脑

拥有自己的应用程序自由运行

使用我们通过 tcp/ip

访问的第三方数据库

然而 我的 Specflow 场景对于我自己的开发设置来说似乎太专业了 :它包含仅对我有效的输入。在下面的示例中，我主要可以访问 IP 地址。目标目录就是我机器上的一个目录。

经认可的测试人员/验证人员或产品所有者可能无法启动相同的测试场景，因为他们无法访问这台机器。但我的开发者同事也可能不会。

@lastOne
Scenario: Get lattest 3rdParty OCR Data into specified directory
Given I indicate 'database' as the databaseName of third party computer
And I indicate '12.126.42.21' as the ipAddress of the third party computer
And I indicate 'user' as the databaseUser in third party computer
And I indicate 'c:\Temp\test_ocr\' as the destination path where to put the ocr data
And I indicate '2013020800009E' as the truck identifier to be associated with ocr data
When I call the OCR Application program
Then the destination path should contain correctly named xml file, with validated xml data, and jpg files about ocr data.

恐怕我对 BDD 有一些误解。我在我的场景中太具体了？
如果是，我应该在哪里停下来？

Answer 1

我不确定您的问题是否特定于 BDD，但它仍然是一个很好的问题。

我通常会建议在每次 checkin 时使用持续集成服务器运行测试来完成所有开发，即使对于您独自工作的私有(private)项目也是如此。甚至我自己的个人项目也能获得此功能，因为 TeamCity 是免费的，而当我签到时，家里的 child 桌面是空闲的。如果您在团队中工作，这一点的重要性会更加明显，因为当您获得它将构建的最新源代码。

但这也可以解决您遇到的问题。当某些东西过于具体时，您可以很快分辨出来，因为它在您自己的个人机器和构建机器上都不起作用。无论您从事 BDD、TDD、ATDD 还是任何类型的测试，这些问题都存在。

看看你上面的例子，我会说它非常具体，也很脆弱。如果有一天第三方电脑被关闭，你所有的测试都会失败。如果您使用 Specflow 运行单元测试，那么我建议您模拟您的大部分代码，这样您就可以在不调用测试 PC 的情况下进行测试，但是您的示例读起来更像是您正在尝试进行系统/集成测试。

与其单独指定所有参数，不如为整个包命名

Given Im using the test pc

然后你可以在绑定(bind)中设置它们中的许多，如果你需要然后定制它们以便测试仍然通过

[Given]
public void GivenImUsingTheTestPc()
{
  if (Environment.ComputerName == "d1234")
  {
    ipadress = 1.2.3.4;
    ....

这显然只会移动脆弱性，但至少它让你现在继续前进