您好我正在开发一个相当简单的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
但这对我来说有点太不明确了。播放列表中有哪些任务?他们的依赖关系是如何定义的?等等......有人能给我一些建议吗?
答案 0 :(得分:1)
你所看到的是一个很好的起点。
您编写的场景是声明性的,即您声明要发生的事情而不确切地说明它应该如何发生:
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
同样,它的声明性和实际细节(例如播放列表中的哪些任务及其依赖关系)将在步骤定义中实现。
答案 1 :(得分:0)
这是一个非常好的问题,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