BDD:当SUT尚未开发时，如何为集成测试编写步骤定义

Question

理想情况下，使用BDD的外部开发风格，您必须首先编写带有相关步骤定义的场景。那就让它失败。然后编写足够的应用程序代码来传递它。

我的问题是，在实际的场景中，如果没有selenium可以用来在step定义中执行业务逻辑层或模型测试的UI，那么如何能够编写集成测试的步骤定义。

我是不是漏掉了什么？我是新来的BDD，这真是令人困惑。请分享你的实践经验，不要理论。

编辑：

例如:一个客户想要一个电子商务网络应用程序。最初要求提供通常的功能，例如：

产品挂牌库

购物车

多种付款选项的结帐

电子邮件通知

根据我对外部开发过程的理解(这可能是错误的)：

1)在对上述用户故事进行分析之后，我将使用Gherkin编写场景规范。

2)然后为这些场景编写步骤定义(我如何编写它们，因为没有任何UI或应用程序类可供使用)

3)我运行这些失败的场景

4)然后开发人员编写一些应用程序代码，使我的方案通过。

5)然后重构我的步骤定义。

Answer 1

您所谓的场景描述只是一个关于应用程序必须包含哪些特性的草案。应该是这样的，而不是使用gherkin语法

Feature: Product Listing Gallery
  To be able to order 
  The Customers should be able to
  Browse a product list

  Scenario: Listing products without filters
    Given Susan is a Customer
    When Susan asks for a product list
      And does not give any filters
    Then she should get a list of products 
      But only products the store has in stock will be listed

  ...

因此，您可以在特性文件中包含许多场景，并且每个场景都描述了一个用例。在将用例写入这些文件之后，可以添加步骤定义。

故事的这一部分类似于多态。通过多态性，您定义了一个接口，它描述了抽象(要做什么)，还有类，它们以特定的方式(如何实现)实现接口。如果你还没有感觉到这种类比:特性描述是关于该做什么，而步骤定义是关于如何去做的。我认为很明显，您可以使用具有相同特性描述的许多不同类型的步骤定义，就像许多类可以通过多态性实现相同的接口一样。因此，如果要测试整个应用程序，可以编写e2e测试步骤定义。如果要对GUI进行分离测试，可以编写GUI测试步骤定义并模拟业务逻辑。您可以编写域模型测试步骤定义，并模拟出GUI和持久性，如果您想测试业务逻辑的分离，等等……

您可以在相同的特性文件中使用所有这些不同的步骤定义。因此，如果实现细节发生变化，例如更改GUI布局，那么唯一需要修改的是使用GUI的步骤定义，而不是只包含抽象的特性文件。

要回答这个问题，你不需要在外部开发。如果您在DDD中使用BDD，那么您可以先开发域模型，然后使用具有不同步骤定义的相同特性文件来开发GUI。如果您想从GUI开始，那么您应该首先模拟业务逻辑并测试GUI。之后，您可以编写步骤定义，以测试业务逻辑的分离性。与使用e2e测试开发整个应用程序相比，这样做更好，因为e2e测试比较慢。我不支持后一种方法，因为我认为考虑域模型更好，而不受GUI、数据库结构和其他因素的影响。Ofc。这些只是我对BDD应该如何发展的印象。