嗨，我正在开发一个相当简单的C#应用程序，并希望利用这种可能性来深入研究BDD。我想我理解了基本的原则，但是我很难将它们应用到我的应用程序中。
更具体地说，我不知道如何将我的需求“转换”为特性/规格和场景。
应用程序的目的是以由这些任务之间的依赖关系定义的特定顺序执行不同的任务，即任务A不能在任务B成功完成之前启动。
应用程序有两个部分，一个是配置向导，用于配置任务及其依赖项以及某种“播放列表”，另一个是运行这些播放列表的实际应用程序。
因此，用户首先配置任务及其依赖关系，然后通过定义他最终想要执行的任务来创建播放列表——然后，应用程序会在由于依赖关系而需要添加额外的任务，并将它们按正确的顺序排列以满足依赖关系。
我可以想象如何为配置向导构建我的场景，例如:(也可以随意评论；))
Given An empty Playlist
And Task A depends on Task B
When The user adds Task A to the list
Then Task B should be added to the list first
And Task A should be added to the list second
但对于运行这些播放列表的部分，我对如何在定义明确的场景中划分需求感到有点困惑。我可以想到这样的事情（幸福之路）：
Given A playlist
When The user executes the list
Then The Tasks should be executed in the correct order
但对我来说，这有点太不明确了。播放列表中有哪些任务？它们的依赖关系是如何定义的？等等...有人能给我一些建议吗？
你所拥有的看起来是一个很好的起点。
你写的场景是声明性的，即你声明你想要发生的事情，而没有具体说明它应该如何发生：
Given A valid playlist
When The user executes the list
Then The Tasks should be executed in the correct order
采用这种方法意味着在步骤定义中定义了关于如何执行这些步骤的细节。声明式测试的一个优点是
关于：
播放列表中有哪些任务？它们的依赖关系是如何定义的？等等...
如果你问企业主他们希望应用程序如何运行，他们更有可能以声明的方式描述他们想要什么(例如，在你给出的例子中)。
对于不愉快的路径示例，产品负责人可能会说:
Given an invalid playlist
When a user executes the list
Then the application should inform them of the error that occurred
同样，它是声明性的，实际的细节(例如，哪些任务在播放列表中，它们的依赖关系)将在步骤定义中实现。
可以在这里和这里找到几篇关于声明性测试的好文章。也可以看到这个答案。
这是一个非常好的问题，IMO 这真的取决于你想要什么。有时指定一个场景就足够了，例如
Given A valid playlist
When the user executes the list
Then the tasks should be executed in the correct order
这对一个企业主来说可能已经足够了，然而，对我来说，这实际上是不够具体的。因为这种情况下会立即出现两个问题:什么是有效的播放列表，什么是正确的顺序。有一个这样的一般场景可能没什么问题，但我宁愿尝试给出一个更具体甚至多个例子。例如:
Given a playlist with tasks A,B,C
And task A depends on B
When the user executes the list
Then the tasks should be played in the order B,A,C
