ATDD与BDD以及框架的正确使用 [英] ATDD versus BDD and the proper use of a framework

问题描述

我只是进入BDD的概念，并听了Scott Bellware与Herding Code团队的谈话.我一直在玩SpecFlow，并且非常喜欢.

I am just getting into the concept of BDD and have listened to Scott Bellware's talk with the Herding Code guys. I have been playing around with SpecFlow some and like it pretty well.

我了解博客文章对BDD工具进行分类(单元测试驱动与验收测试驱动)以及一些BDD历史记录，但这使我提出了一个问题.

I understand the distinction between ATDD and TDD as described in the blog post Classifying BDD Tools (Unit-Test-Driven vs. Acceptance Test Driven) and a bit of BDD history, but that leads me to a question.

如上所述，难道不使用BDD工具(例如MSpec)只是另一个单元测试框架吗?在我看来是这样.

As described, isn't using a BDD tool (such as MSpec) just another unit testing framework? It seems to me that it is.

此外，这似乎表明使用SpecFlow来确定较低级别的组件(例如您的存储库和服务)将是错误的.如果我可以对较低级别的组件的ATDD和TDD使用相同的工具，为什么不呢?似乎仍然有些模糊的线条让我觉得我不太了解.

Furthermore, this seems to suggest that using SpecFlow to spec out the lower level components (such as your repositories and services) would be wrong. If I can use the same tool for both ATDD and TDD of lower level components, why shouldn't I? There seems to still be some blurry lines here that I feel like I'm not quite understanding.

推荐答案

快速解答

提出的一个非常重要要点是，有两种行为驱动的开发.这两种是 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(非常类似于Ruby堆栈中的黄瓜)，它在促进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.

对于在单位级别进行行为驱动的开发，我建议 NSpec (启发直接由 RSpec (对于Ruby).您可以通过简单地使用NUnit或MSTest在单元级别上完成BDD ...但是它们有点不足(以增量方式构建上下文确实很困难). MSpec 也是一种选择，已经投入了大量工作它，但是在NSpec中只是一些简单的东西(您可以在MSpec中逐步建立上下文，但是它需要继承，而继承可能会变得很复杂).

For behavior driven development on a unit level, I would recommend NSpec (inspired directly by RSpec for Ruby). You can accomplish BDD on a unit level 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, there has been a lot of work put into it, but there are just somethings that are just simpilier in NSpec (you can build up context incrementally in MSpec, but it requires inheritance which can become complex).

BDD的两种风味之所以存在，主要是因为它们提供了正交的好处.

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

• 帮助通过称为(例如，给定....，给定....，何时......，何时.....，然后..的普通方言)促进与企业的对话. ..，然后)
• 然后可以将常用方言映射到可执行代码，该代码向企业证明您实际上完成了您所说的要完成的事情
• 方言是紧缩的，因此企业必须消除歧义，使其适合句子.

• 虽然xBehave方法适合于驱动高级接受标准，但通过属性将英语映射到可执行代码所需的周期使得在单元级别驱逐域变得不可行.
• 将常用方言映射到测试是PAINFUL(在正则表达式上增强).企业创建的每个句子都必须通过属性映射到可执行方法.
• 必须严格控制常用方言，以免管理映射.每次更改句子时，都必须找到与该句子直接相关的方法并修复正则表达式匹配.

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

• 该业务不那么可及.面对现实吧，企业不希望消除歧义.如果我们为他们提供基于上下文的BDD方法，那么该句子将显示为"Just make it work".
• 一切都在代码中.上下文文档在代码中交织在一起(这就是为什么我们不必担心将英语映射到代码)
• 由于限制词较少，因此不易阅读.

Bowling Kata 很好例子.

这是SpecFlow在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

步骤定义文件

步骤定义文件是测试的实际执行，该文件包含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";
    }

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

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);
    }
}

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

随着您做越来越多的BDD，您会发现BDD的xBehave和xSpec风味都是必需的. xBehave更适合于验收测试，xSpec更适合于单元测试和域驱动设计.

So Yea...SpecFlow is cool, NSpec is cool

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.

• RSpec vs黄瓜(RSpec故事)
• 带有Cucumber和rspec的BDD-什么时候冗余?
• NSpec项目站点
• 连续测试
• BDD和模拟的介绍
• 使用NUnit和Moq进行BDD

• RSpec vs Cucumber (RSpec stories)
• BDD with Cucumber and rspec - when is this redundant?
• NSpec Project Site
• Continuous Testing
• Introduction to BDD and Mocking
• BDD using NUnit and Moq

这篇关于ATDD与BDD以及框架的正确使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！