理想情况下，使用BDD的从外开发风格，您必须首先使用关联的步骤定义编写方案。然后失败了。然后编写足够的应用程序代码以使其通过。
我的问题是，在一个真实的场景中，当没有开发出任何可以由selenium用于在OR上实现页面对象的UI时，如何编写集成测试的步骤定义是可能的。在步骤定义中用于执行业务逻辑层或模型测试。
我在这里遗漏了什么吗？我是BDD的新手，这真的令人困惑。请分享您的实践经验，请不要理论。
修改
示例场景：
客户想要一个电子商务网络应用程序。最初要求通常的功能，如：
产品列表图库
购物车
结账时有各种付款方式
电子邮件通知
根据我对外部开发过程的理解（可能是错误的）：
1）在分析上述用户故事后，我将使用Gherkin编写场景规范
2）然后为这些场景编写步骤定义（如何编写它们，因为没有任何UI或应用程序类可供使用）
3）我运行这些失败的情况
4）然后开发人员编写一些应用程序代码，使我的场景通过
5）然后重构我的步骤定义。
答案 0 :(得分：0)
您所谓的场景描述只是关于应用程序必须包含哪些功能的草稿。它应该是这样的，而不是使用gherkin syntax：
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的步骤定义，而不是仅包含抽象的特征文件。
要回答这个问题，你不需要从外到内发展。如果将BDD与DDD一起使用，则可以首先开发域模型，然后使用具有不同步骤定义的相同功能文件来稍后开发GUI。如果您想从GUI开始，那么您应该先模拟业务逻辑并首先在分离中测试GUI。之后，您可以编写用于在分离中测试业务逻辑的步骤定义。这种方式比使用e2e测试开发整个应用程序更好，因为e2e测试很慢。我不支持后一种方法，因为我认为在不受GUI，数据库结构和其他因素影响的情况下考虑域模型会更好。 OFC。这些只是我对BDD如何发展的印象。