我们首次尝试为绿地应用编写一些Gherkin规范，但我不确定如何解决看似相互依赖的功能。
基本上，我们有一个功能CreateADoor实际上用作其他两个功能BuildAHouse和BuildAShed的一部分。
CreateADoor功能在验证等方面相对复杂，这就是为什么我们将其作为一个单独的功能解除（以避免重复）。问题是此功能的场景的结果取决于它们被调用的上下文（如果我新建的门在House或Shed上）。
我能真正看到解决此问题的唯一方法是摆脱CreateADoor并在BuildAHouse和BuildAShed内重复其方案。在这种特定的情况下，这将是（几乎）可忍受的，但是CreateADoor需要10个场景来规范它的情况如何，并被10个不同的特征使用。将10个场景分解为100个似乎不太好，但我现在看不到另一个选项。
任何人都可以提出一种不同的方法，以避免这种情况爆发吗？
答案 0 :(得分：0)
理想情况下，您不应该创建这些依赖项，而是如果创建一个门是构建房屋的一部分，那么构建房屋功能应该创建一个门作为其设置的一部分，而不是重新使用该功能来测试创建一个门。 / p>
这可能如下所示：
Given I have created a house door
When I create a house
Then I should be able to live in it
并且创建门的逻辑应该在Given步骤后面的代码中。这种逻辑可能与您在测试中创建门时实际发生的情况大不相同。
如果您无法将此类内容分开，那么我过去做的一件事就是让Given步骤后面的代码调用CreateADoor功能中的其他步骤，以便代码不重复，但重用现有步骤。这不是理想的，但实际上这有时是必要的。