什么是最成熟的BDD框架.NET？ [英] What is the most mature BDD Framework for .NET?

问题描述

我们一直在使用 BDD - 行为驱动开发（从丹北的角度来看）作为一种机制来记录用户验收测试并推动发展上几个项目，体面的成功。到目前为止，虽然我们还没有真正的自动化测试本身。

We have been using BDD - Behaviour Driven Development (from Dan North's perspective) as a mechanism to record user acceptance tests and drive development on a couple of projects, with decent success. To date though we have not actually automated the tests themselves.

我现在在寻找到自动化测试，但我不知道备份哪些行为框架。到目前为止NBehave似乎是先驱 - 但是否有任何其他我应该看什么？是否有一个明确的赢家的时刻？

I am now looking in to automating the tests, but I am not sure which behaviour framework to back. So far NBehave seems to be the forerunner - but are there any others I should be looking at? Is there a clear 'winner' at the moment?

推荐答案

一个非常重要点提出的是，有行为的两种口味驱动开发。的两种口味是 xBehave 和<强> xSpec 。

The Quick Answer

One very important point to bring up is that there are two flavors of Behavior Driven Development. The two flavors are xBehave and xSpec.

SpecFlow（非常相似，从红宝石堆栈黄瓜）具有良好的促进xBehave BDD测试，验收标准。但是，它没有提供给写在单元级行为测试的好方法。还有一些其他的xBehave测试框架，但SpecFlow已经得到了很多的牵引力。

SpecFlow (very similar to cucumber from the Ruby stack) is excellent in facilitating xBehave BDD tests as Acceptance Criteria. It does not however provide a good way to write behavioral tests on a unit level. There are a few other xBehave testing frameworks, but SpecFlow has gotten a lot of traction.

客观地讲。给出可用的上下文规格框架，MSpec一直围绕最长，在净社区最广泛使用的上下文/规范框架

Objectively speaking. Given the context specifications frameworks available, MSpec has been around the longest and is the most widely used context/specification framework in the .Net community.

我个人会建议 NSpec （由 RSpec的直接启发为Ruby）。充分披露，我NSpec的作者之一。可以实现BDD通过简单地使用NUnit和MSTest的...但他们有点功亏一篑（这真的很难建立环境增量）。 MSpec 也是一种选择，也是最成熟的上下文/规范框架.NET。 但是的，也有只是一些事情是在NSpec简单。

I personally would recommend NSpec (inspired directly by RSpec for Ruby). Full disclosure, I am one of the authors of NSpec. You can accomplish BDD by simply using NUnit or MSTest...but they kinda fall short (it's really hard to build up contexts incrementally). MSpec is also an option and is the most mature context/specification framework for .Net. But, there are just some things that are simpler in NSpec.

BDD的两​​种形式，主要是因为它们提供正交利益存在。

The two flavors of BDD primarily exist because of the orthogonal benefits they provide.

• 有助于通过共同的方言被称为促进与业务会话（如：鉴于...，并给予....，当......，当......，那么...... ..，然后）
• 通用​​方言可以被映射到可执行code这证明你实际完成你说的话，你会完成业务
• 方言是收缩的，所以企业必须消除歧义的要求，并使其融入句子。

• 当xBehave做法有利于推动高水平的验收标准，需要英语映射通过属性的可执行文件code中的循环使得它不可能驱除在单元级别域。
• 通用​​方言映射到测试是痛苦的（坡道上你的正则表达式）。每个句子的业务产生必须通过属性映射到可执行的方法。
• 在共同的方言必须严格控制，使得管理映射不失控。你改变一个句子任何时候，你必须要找到方法，它直接关系到这句话并修复正则表达式匹配。

• 允许开发人员逐步建立环境。上下文可以设置为一个测试和一些断言可以针对该上下文来执行。然后，您可以指定更多的情况下（在已经存在的情况下建设），然后指定更多的测试。
• 在无约束的语言。开发者可以是关于如何的系统的某些部分的行为更前pressive。
• 无英语和共同的方言（因为没有一个）。
之间所需的映射

• Allows the developer to build up context incrementally. A context can be set up for a test and some assertions can be performed against that context. You can then specify more context (building upon the context that already exists) and then specify more tests.
• No constricting language. Developers can be more expressive about how a certain part of a system behaves.
• No mapping needed between English and a common dialect (because there isn't one).

• 不是由业务平易近人。让我们面对现实吧，企业不喜欢歧义他们想要的东西。如果我们给了他们一个基于上下文的方法来BDD那么一句只想读只要它的工作。
• 一切都在code。上下文文档中的code交织在一起（这就是为什么我们不担心映射英语code）
• 还不如读给限制较少的空话。

借助保龄球卡塔是pretty的很好的例子。

The Bowling Kata is a pretty good example.

下面是本规范是什么样子的SpecFlow（同样，这是伟大的验收测试，因为它直接与业务）：

Here is what the specification would look like in SpecFlow (again, this is great as an acceptance test, because it communicates directly with the business):

该功能的文件是常见的方言进行测试。

The feature file is the common dialect for the test.

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

Scenario: Single Pin
  Given a new bowling game
  When I've hit exactly 1 pin
  Then my total score should be 1

步骤定义文件

的步骤的定义文件是测试的实际执行中，该文件包括映射SpecFlow

Step Definition File

The step definition file is the actual execution of the test, this file includes the mappings for 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";
    }

    [When(@"I've hit exactly 1 pin")]
    public void When1PinIsHit()
    {
        _game.Frames = "10000000000000000000";
    }

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

MSpec样品，xSpec，上下文/规范

public class describe_BowlingKata
{
    public static Game game;

    public class when_all_balls_land_in_the_gutter : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "00000000000000000000";

        It should_have_a_score_of_0 = () => game.Score.ShouldBe(0);
    }

    public class when_a_single_pin_is_hit : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "10000000000000000000";

        It should_have_a_score_of_1 = () => game.Score.ShouldBe(1);
    }
}

NSpec样品，xSpec，上下文/规范

下面是一样的保龄球卡塔的 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);
    }

    void when_a_single_pin_is_it()
    { 
        before = () => game.Frames = "10000000000000000000";

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

当你这样做越来越多的BDD，你会发现，需要BDD的两​​个xBehave和xSpec味道。 xBehave更适合验收测试，xSpec更适合单元测试和领域驱动设计。

As you do more and more BDD, you'll find that both the xBehave and xSpec flavors of BDD are needed. xBehave is more suited for Acceptance Tests, xSpec is more suited for unit tests and domain driven design.

如年龄和稳定性目标的指标应该是一个因素，我会鼓励大家考虑这一点。但也请考虑到新的框架，可以提供更简洁的API，更好地利用语言结构和建设的经验教训为过去的框架。 MSpec提供给定结构，因为，它和Cleanup..but他们付出了代价：静态初始化所有成员，类爆炸，这是因为其独特的使用代表语法的刚性。你会发现，最简单的MSpec测试是在NSpec简单。下面是一个更复杂的测试套件写无论是在MSpec和NSpec。

Objective metrics like age and stability should be a factor, and I would encourage everyone to take that into consideration. But please also take into consideration that newer frameworks may provide a more succinct api, better usage of language constructs and build on lessons learned for past frameworks. MSpec provides constructs of Given, Because, It and Cleanup..but they come at a cost: static initialization for all members, class explosion, and it's syntactically rigid because of its unique use of delegates. You'll find that the simplest MSpec tests are simpler in NSpec. Here is a more complex test suite written both in MSpec and NSpec.

的xUnit，MSpec和NSpec的比较： https://gist.github.com/amirrajan/6701522

A Comparison of xUnit, MSpec and NSpec: https://gist.github.com/amirrajan/6701522

RSpec的VS黄瓜（RSpec的故事）

<一个href="http://stackoverflow.com/questions/3736808/bdd-with-cucumber-and-rspec-when-is-this-redundant">BDD黄瓜和RSpec的 - 如果是这样的冗余

这篇关于什么是最成熟的BDD框架.NET？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！