ATDD与BDD以及框架的正确使用

Question

我刚刚进入BDD的概念,并听取了Scott Bellware与Herding Code人员的谈话.我一直在玩SpecFlow,并且非常喜欢它.

我理解ATDD和TDD之间的区别,如博客文章分类BDD工具(单元测试驱动与接受测试驱动)和一些BDD历史中所述,但这引出了一个问题.

如上所述,是不是使用BDD工具(如MSpec)只是另一个单元测试框架？在我看来它是.

此外,这似乎表明使用SpecFlow来规划较低级别的组件(例如您的存储库和服务)将是错误的.如果我可以将同一工具用于较低级别组件的ATDD和TDD,为什么我不应该？这里似乎仍然有一些模糊的线条,我觉得我不太了解.

Answer 1

快速回答

提出一个非常重要的一点是,行为驱动开发有两种风格. 这两种口味是xBehave和xSpec.

xBehave BDD:SpecFlow

SpecFlow(非常类似于Ruby堆栈中的黄瓜)非常适合将xBehave BDD测试作为Acceptance Criteria.然而,它并没有提供在单元级别编写行为测试的好方法.还有一些其他xBehave测试框架,但SpecFlow已经获得了很大的吸引力.

xSpec BDD:NSpec

对于单元级别的行为驱动开发,我建议使用NSpec(直接受RSpec for Ruby 启发).您可以通过简单地使用NUnit或MSTest来完成单元级别的BDD ...但它们有点不足(很难逐步建立上下文). MSpec也是一个选项,已经有很多工作,但在NSpec中只有一些简单的东西(你可以在MSpec中逐步建立上下文,但它需要继承,这可能变得复杂).

答案很长

两种BDD主要存在,因为它们提供了正交的好处.

xBehave(GWT语法)的优点和缺点

优点

• 通过一种叫做的公共方言(例如,给定......,给定......,当......,和当......,然后......),有助于促进与业务的对话.然后)
• 然后可以将普通方言映射到可执行代码,这可以向业务证明您实际完成了您所说的完成内容
• 方言是收缩的,所以企业必须消除要求的歧义并使其适合句子.

缺点

• 虽然xBehave方法有利于推动高级接受标准,但是通过属性将英语映射到可执行代码所需的周期使得在单元级别驱逐域不可行.
• 将普通方言映射到测试是痛苦的(提升你的正则表达式).业务创建的每个句子必须通过属性映射到可执行方法.
• 必须严格控制普通方言,以便管理映射不会失控.每次更改句子时,都必须找到与该句子直接相关的方法并修复正则表达式匹配.

xSpec(上下文/规范)的优点和缺点

优点

• 允许开发人员以增量方式构建上下文.可以为测试设置上下文,并且可以针对该上下文执行一些断言.然后,您可以指定更多上下文(基于已存在的上下文),然后指定更多测试.
• 没有限制语言.开发人员可以更加表达系统某个部分的行为方式.
• 英语和普通方言之间不需要映射(因为没有一个).

缺点

• 不像业务那样平易近人.让我们面对现实,企业不喜欢消除他们想要的东西.如果我们给他们一个基于上下文的方法来处理BDD,那么句子只会读作"Just make it work".
• 一切都在代码中.上下文文档在代码中交织在一起(这就是我们不必担心将英语映射到代码的原因)
• 鉴于限制性较低的措辞,不具备可读性.

样品

该保龄球卡塔是一个很好的例子.

SpecFlow示例

以下是规范在SpecFlow中的样子(再次,这是一个很好的验收测试,因为它直接与业务通信):

特征文件

特征文件是测试的常用方言.

Feature: Score Calculation 
  In order to know my performance
  As a player
  I want the system to calculate my total score

Scenario: Gutter game
  Given a new bowling game
  When all of my balls are landing in the gutter
  Then my total score should be 0

步骤定义文件

步骤定义文件是测试的实际执行,该文件包含SpecFlow的映射

[Binding]
public class BowlingSteps
{
    private Game _game;

    [Given(@"a new bowling game")]
    public void GivenANewBowlingGame()
    {
        _game = new Game();
    }

    [When(@"all of my balls are landing in the gutter")]
    public void WhenAllOfMyBallsAreLandingInTheGutter()
    {
        _game.Frames = "00000000000000000000";
    }

    [Then(@"my total score should be (\d+)")]
    public void ThenMyTotalScoreShouldBe(int score)
    {
        Assert.AreEqual(0, _game.Score);
    }
}

NSpec Sample,xSpec,Context/Specification

这是同一个保龄球kata 的NSpec示例:

class describe_BowlingGame : nspec
{
    Game game;

    void before_each()
    {
        game = new Game();
    }

    void when_all_my_balls_land_in_the_gutter()
    {
        before = () =>
        {
            game.Frames = "00000000000000000000";
        };

        it["should have a score of 0"] = () => game.Score.should_be(0);
    }
}

所以...是的... SpecFlow很酷,NSpec很酷

当您执行越来越多的BDD时,您会发现需要BDD的xBehave和xSpec风格.xBehave更适合验收测试,xSpec更适合单元测试和域驱动设计.

相关链接

• RSpec与黄瓜(RSpec故事)
• 使用Cucumber和rspec的BDD - 何时多余？
• NSpec项目现场
• 持续测试
• BDD和Mocking简介
• BDD使用NUnit和Moq

Answer 2

真正的行为驱动工具就像Cucumber.我们在针对.NET代码的工作中使用它.这允许我们编写定义系统整体行为的功能,然后我们可以执行这些功能并验证系统是否符合我们的预期.整个过程对我们来说非常有效.

http://cukes.info/

有一个名为NStep的.net实现,它通过有线协议连接到黄瓜,它允许你使用lambdas在C#中编写步骤定义...它非常棒.

步骤定义如下所示:

When("^I go to the \"([^\"]*)\" (?:[Ss]creen|[Pp]age)$", (string pageName) =>
{
    var screen = ParseScreen(pageName);
    GoToScreen(screen);
    World.Browser.Wait(1000);
});

http://github.com/clearwavebuild/nStep