.NET 最成熟的 BDD 框架是什么？[关闭]

StackOverflow https://stackoverflow.com/questions/307895

  •  08-07-2019
  •  | 
  •  

题

我们一直在使用 BDD-行为驱动开发 （从 Dan North 的角度来看）作为记录用户验收测试并推动几个项目开发的机制，取得了相当大的成功。但迄今为止，我们还没有真正实现测试本身的自动化。

我现在正在考虑自动化测试，但我不确定要支持哪个行为框架。到目前为止，NBehave 似乎是先行者 - 但还有其他我应该关注的吗？目前有明显的“赢家”吗？

有帮助吗？

解决方案

快速回答

一 很重要 需要提出的一点是，有 行为驱动开发的两种风格。 两种口味分别是 x行为 和 规格.

xBehave BDD：规格流

SpecFlow（非常类似于 黄瓜 来自 Ruby 堆栈）在促进 xBehave BDD 测试作为验收标准方面表现出色。然而，它并没有提供在单元级别编写行为测试的好方法。还有其他一些 xBehave 测试框架，但 SpecFlow 已经获得了很大的关注。

xSpec BDD：M规格

客观地说。考虑到可用的上下文规范框架，MSpec 是 .Net 社区中历史最长且使用最广泛的上下文/规范框架。

另一个 xSpec BDD 框架：国家规范

我个人会推荐 国家规范 （直接受到启发 规格 对于红宝石）。完全公开，我是 NSpec 的作者之一。您可以通过简单地使用 NUnit 或 MSTest 来完成 BDD...但它们有点不足（增量构建上下文真的很难）。 M规格 也是一种选择，并且是 .Net 最成熟的上下文/规范框架。 但, ，只是 NSpec 中有些东西更简单。

长答案

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

Scenario: Single Pin
  Given a new bowling game
  When I've hit exactly 1 pin
  Then my total score should be 1
步骤定义文件

步骤定义文件是测试的实际执行，该文件包含 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、上下文/规范

这里有一个 国家规范 相同保龄球型的示例：


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 更适合单元测试和领域驱动设计。

MSpec 与 NSpec

年龄和稳定性等客观指标应该是一个因素，我鼓励每个人都考虑到这一点。但也请 考虑到新的框架可能会提供更简洁的 API、更好地使用语言结构并借鉴过去框架的经验教训. 。MSpec 提供了 Give、Because、It 和 Cleanup 的构造……但它们是有代价的：所有成员的静态初始化、类爆炸，并且由于其对委托的独特使用，它在语法上是严格的。您会发现最简单的 MSpec 测试在 NSpec 中更简单。这是用 MSpec 和 NSpec 编写的更复杂的测试套件。

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

相关链接

RSpec 与 Cucumber（RSpec 故事）

BDD with Cucumber 和 rspec - 什么时候这是多余的？

其他提示

查看 SpecFlow 。

这是一款受Cucumber启发的工具，旨在为.NET项目的验收测试驱动开发和行为驱动开发提供一种实用且无摩擦的方法。

VisualStudio集成似乎特别有希望。

StoryQ 通过其Fluent界面看起来是NBehave的不错替代品。我肯定会检查出来。

我不认为真的有'胜利者'。其他框架包括 SpecUnit.NET 项目和 MSpec 也显示了 Gallio 适配器的开头。技术上，自IronRuby即将出现以来， rSpec 可能是那些准备进入前沿的人的选择。 NBehave + NSpec可能是最好的自动化框架，尽管我发现自己正在反对过于冗长的语法。

我会全力检查它们并选择最适合您项目风格的框架。它们都是OSS，所以它很难输，真正的好处只是转向BDD。

我个人会推荐BDDfy这在我看来很棒！它是开源的，支持常规和流畅的场景描述，涵盖了很好的接受和单元测试。您可以在 GitHub 上找到它。

机器人框架也可以与 IronPython 一起使用.Net中的ATDD或BDD。我认为Robot Framework的表达能力比例如。 SpecFlow 或 NSpec 。它不会强制您使用某种语法，而是使用关键字驱动的方法。如果您正在测试Web应用程序，它有 Selenium2Library ，它提供了对Selenium WebDriver的绑定。

还有幽灵，它定义了Boo中的DSL，使其更加自然。

我通常会支持NBehave，结合MbUnit以及您需要的任何DI /模拟框架。 Jim Burger公平地评论说NBehave非常冗长，我发现自己有时会使用剪切和粘贴。不过，它运行得很好 - 我正在使用Gallio的ReSharper插件，所以我只是得到一个额外的窗口显示。但是，还没有尝试使用ccnet。

查看此博客文章及其评论，以获得鼓舞人心的想法： http ：//haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Concordion.NET 不仅支持BDD，还支持ATDD： http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-的atdd / 规格用简单的英文写成使用HTML。恕我直言，这是Concordion.NET的好处之一。可以将HTML文档组织成可导航的结构，以构建生活文档系统。而且，由于测试是针对系统运行的，因此您可以确信文档始终是最新的。

我开始在BDD首次参加我的团队的小型应用程序。我们选择执行此工作的工具有：使用 Selenium Webdriver for xBehave的Specflow故事和MSpec与 Machine.Fakes.Moq 的automocking容器我们的xSpec单元测试。由于Specflow和MSpec支持的集成，Resharper既是我们的故事跑者又是规格跑者。使用R＃本地集成到visual studio中是我们的一个关键特性。

由于我们的设计都是MVC3，我们也将应用我们的MVC控制器的协调器分离模式。这将允许我们直接针对协调器编写规范。然后让我们直接针对我们的应用程序使用来编写故事。

由于我现在正在处理BDD以进行安全关键应用程序的系统测试，我只能分享我的经验，你不应该低估用自然语言编写的测试的力量<！>;而不是<！> quot; code <！> quot;。

我们一直专注于提供一种功能语言，任何人都可以在没有任何技术背景或编程经验的情况下理解（参见上面的specflow示例），我们做得很好。除了我从未向任何人解释语法之外，每个人都立即理解测试，开发人员，经理甚至测试人员的意义。

我会以任何方式避免用编程语言编写的测试，例如上面的MSpec示例。如果我在经理办公室出现这样的测试，他会把我踢出去。但他有兴趣阅读基于Gherkin-Syntax的测试。能够阅读和修改测试的人越多越好。

最后但并非最不重要的是，这些测试可以移植到任何其他编程语言，任何其他平台，任何其他测试自动化工具，而无需任何更改。

同样，答案还有一次：

不要关心工具及其功能本身，选择一种工具，让您可以随时轻松切换到其他工具而不会丢失信息。工具来来去去，我的测试应该持续更长时间。 ： - ）

我可以推荐使用SpecFlow。您可以完全访问完整的.Net库及其所有功能，您的测试可以保持便携。如果您不介意可移植性，这可能会使您比完全可移植的解决方案（如Robot Framework）更具优势。但是，通过使用不同的工具进行开发和测试，您始终可以提高系统的稳定性和可移植性。因此，在某些情况下，使用基于python的BDD方法测试.Net软件可能是一个好的（甚至更好的）。

然而，SpecFlow在每天测试中都显示出稳定和防弹，包括在中型项目中进行夜间构建测试等。此外，它还可以很好地集成到Microsoft单元测试环境中。

另请查看UBADDAS，特别是

中找到的UAT

https://github.com/KernowCode/UBADDAS

这里有解释

http://kernowcode.wordpress.com/ （2014年6月）

你可以写一个像这样的测试

[Test]
public void IWantToRegisterANewUser()
{
  var user = new User();
  ICustomer customer = new Customer();

  SoThat(MyBusinessValue.IncreaseCustomerBase)
    .As(user)
    .Given(customer.Register)
    .When(customer.Confirm_Registration)
    .Then(customer.Login);
}

并生成此

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top