BDD 测试是验收测试吗？

Question

如果您有 BDD 测试，您是否需要像 Fitnesse 这样的东西？

Answer 1

BDD“测试”存在于多个不同的粒度级别，一直到最初的项目愿景。 大多数人都知道这些场景。 有些人还记得 BDD 以“应该”一词开头作为 JUnit 的“测试”的替代品“ - 作为 TDD 的替代品。 我将“测试”放在引号中的原因是因为 BDD 并不是真正关于测试；而是关于测试。 它的重点是发现缺乏理解或不匹配的地方。

由于这种关注，对话比 BDD 工具重要得多。

我要再说一遍。 对话比 BDD 工具重要得多。

验收测试实际上并不强制进行对话，并且通常假设您正在编写的测试是正确的测试。 在 BDD 中，我们假设我们不知道自己在做什么（并且可能不知道我们不知道）。 这就是为什么我们使用“给定、何时、那么”之类的东西 - 这样我们就可以围绕场景和/或单元级示例进行对话。 （这是大多数人熟悉的两个级别 - 相当于验收测试和单元测试 - 但它的规模有所扩大）。

我们不称其为“验收测试”，因为您不能要求业务人员“请帮助我进行验收测试”。 他们会用一种非常奇怪的眯眼目光看着你，然后将你视为那个极客女孩。 93% 的人不希望这样。

尝试“我想和你谈谈……的场景”。 或者，“你能给我举个例子吗？” 这些都很好。 将它们称为“验收测试”开始让人们认为您实际上在进行测试，这意味着您知道自己在做什么并且只是想确保已经完成了它。 那时，谈话的重点往往是你能多快地找出错误的东西，而不是你正在找出错误的东西这一事实。

而你却搞错了事情。 真的，老实说，你是。即使你认为你'不是，那只是因为你不了解二阶无知。 你不知道自己不知道，这没关系，只要你找到了你可以知道自己不知道的地方。 （您不会找到所有这些。不要让分类悖论让您彻夜难眠。）

真正做到正确的唯一方法是预先了解所有需求，然后您知道当你尝试这样做时会发生什么。 这是正确的。 这是瀑布。 还记得加班吗？ 周末上班吗？ 在这七年里，你创造的任何东西都没有投入生产？ 如果你想避免这种情况，你只有一次机会：假设你错了，进行一些对话以减少错误，然后接受你仍然是错误的事实并继续努力。 太早编写测试意味着你有更多的机会犯错，现在更难改变，每个人都认为你是对的，PM正在衡量你的速度，现在你注定会犯错再坚持两周。 而且 - 更糟糕的是 - 你也将测试你是否错了。

再次。 对话比 BDD 工具重要得多。

请不要只关注工具。 这些工具只是一种捕获对话并确保它们融入代码的机制。 场景不能替代对话，就像 3 x 5 索引卡不能替代需求一样。

话虽如此，如果您必须从一个工具开始，请将 Slim 放在 Fitnesse 后面，这样它就可以运行可爱的给定/何时/然后，而不必弄乱 Fit 的表格和固定装置。 GivWenZen 基于 Slim，两者都很棒。 FitSharp 对于 .NET 领域的人来说是等价的。 或者只是使用 Cucumber、SpecFlow，或者 敲一个小型定制 DSL* 可以在多年内很好地完成工作。

透明度：*那是我写的。 还有一些 JBehave。 我希望我们将其称为“不要集中精力于 BDD 工具行为”。 我可能会大量参与 BDD 的其他部分。 另外，如果我能把这个消息传达出去，丹·诺斯会给我买一品脱啤酒，所以这并不是完全公正的建议。

无论如何 - 已经进行对话了。 这只是人。 去谈谈吧。

Answer 2

严格来说，我不知道是否存在“BDD 测试”这样的东西。 BDD 是一种哲学，它建议您如何最好地与利益相关者进行交互和协作以完成复杂的项目。 它并不直接规定编写测试的最佳方式。 换句话说，您可能仍然需要在 BDD 哲学项目下进行所有常见类型的测试（包括验收测试）。

当您听到“BDD 框架”时，说话者通常指的是用于编写所有常用类型的测试但具有 BDD 风格的框架。 例如，在 RSpec 中，您仍然编写单元测试； 你只需将 BDD 风格添加到其中即可。

Answer 3

虽然 BDD 的范围比单纯的测试更大，但确实存在 BDD 测试。 这些测试是遵循 BDD 语言的单元测试。

给定一些初始上下文（给定的），
当事件发生时，
然后确保一些结果。

根据您的偏好语言，有一些不错的 BDD 框架可供使用。
用于 Java 的 JBehave
用于 Ruby 的 RSpec
NBehave for .NET

Answer 4

我喜欢区分“规格”和“测试”。

如果我要介绍一个名为 GetAverage(IEnumerablenumbers) 的方法，我将编写一个或多或少标准的单元测试。

如果我要介绍一个名为 CalculateSalesTax(decimal amount, State state, Municipality cityity) 的方法，我仍然要编写单元测试，但我将其称为规范，因为我要对其进行更改 (1) 以验证例程的行为，以及 (2) 因为测试本身将记录例程及其验收标准。

考虑：

[TestFixture]
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context
{
    // set up mocks and expected behaviour
    StateSalesTaxWebService stateService 
        = the_dependency<IStateSalesTaxWebService>;
    MunicipalSurchargesWebService municipalService 
        = the_dependency<IMunicipalSurchargesWebService>;

   stateService.Stub(x => x.GetTaxRate(State.Florida))
        .Return(0.6);
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty))
        .Return(0.05);

    // run what's being tested
    decimal result = new SalesTaxCalculator().CalculateSalesTax
        (10m, State.Florida, Municipality.OrangeCounty);

    // verify the expected behaviour (these are the specifications)
    [Test]
    public void should_check_the_state_sales_tax_rate()
    {
        stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions
    }

    [Test]
    public void should_check_the_municipal_surcharge_rate()
    {
        municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty));
    }

    [Test]
    public void should_return_the_correct_sales_tax_amount()
    {
        result.should_be_equal_to(10.65m);
    }
}

Answer 5

JBehave（和 NBehave 最近添加了相同的支持）使用常规测试文件，因此虽然许多其他框架添加了“BDD 品味单元测试”，但使用 JBehave 创建的基于文本的行为规范/示例适合验收测试。 不，你不需要为此进行健身。

为了了解它是如何工作的，我建议JBehaves 2min 教程。

Answer 6

对于 Flex 中的 BDD 测试，您可以尝试 GivWenZen-flex 查看 http://bitbucket.org/loomis/ givwenzen-flex。

干杯，
克里斯

Answer 7

良好实施的 xBehavior BDD 测试是机器人驱动的用户接受标准。

xSpecification BDD 测试通常是单元测试，不太可能成为可接受的用户验收标准。