BDD/TDD与JAD？

Question

我一直建议我的工作场所实现行为驱动开发，通过以场景格式编写高级规范，并以一种可以想象为其编写测试的方式。

我确实知道，违反可测试的规范往往会导致increase developer productivity。我已经想到了几个例子，在我们自己的项目中就是这样。

然而，很难证明这对业务的价值。

这是因为我们已经有了一个联合应用程序开发(JAD)过程，在这个过程中，开发人员、管理人员、用户体验人员和测试人员都聚集在一起，就一组共同的需求达成一致。

因此，他们问，为什么开发人员要针对测试人员创建的测试用例进行工作？这些是为了验证，并基于由UX团队创建的更高级别的规范，开发人员目前正在进行工作。

他们说，这对开发人员来说已经足够了，不需要改变规范的编写方式。

他们似乎说得有道理。

如果你已经有了一个测试团队，他们的测试用例与目前提供给开发人员的高级规范完全兼容，那么BDD/TDD的实际好处是什么？

Answer 1

如果你想让他们相信这会有帮助，你需要做的主要事情是找出它可以解决的问题。

在你的情况下发生了什么，你认为这会有所改善？

BDD的主要好处是改善了利益相关者和开发人员之间的沟通。

如果你生产的代码没有通过这些验证测试，那么开发人员对你的规范的理解与测试人员不同，这意味着该规范缺乏清晰度，BDD肯定可以改善这种情况。

作为一名开发人员，您还可以在不更改整个团队流程的情况下处理流程的某些部分。如果您专注于单元测试级别并进行传统的测试驱动开发，这可能会使您的工作效率更高。

Answer 2

这是一个很好的问题，事实上，当涉及到BDD时，这是一个“底线”问题。TDD或编写单元测试的主要挑战之一是，开发人员似乎永远无法获得事物的更大图景和业务视角。编写规范和生成单元测试的练习来测试实际的“业务”场景，有助于开发人员超越他们的“手艺”，掌握业务前景。请查看这篇文章以了解更多细节，

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 3

以最轻量级的形式考虑BDD可能会有所帮助；作为围绕特定场景的讨论。

你已经有了你的用例。您已经满足了您的需求。现在，您需要验证您是否对这些内容有了很好的理解。所以有人--可能是开发人员，也可能是测试人员--会说，“好吧，只是为了验证我是否理解了……假设我们从一开始就知道，当一个用户这样做时，就应该发生这样的事情。是这样吗？”

测试人员会说：“是的，这是正确的。”

然后用户体验或分析师会说，“嗯，除非它是正确的”。

通过围绕场景进行讨论，确保每个人都有共同理解所需的时间大大减少。我们通常掩盖显而易见的场景，专注于边缘案例；在新的领域术语上，部门之间的概念不同，与遗留系统的困难交互。

开发人员并不是真正从测试用例中工作出来的。他们从需求和验收标准开始工作，就像他们一直做的那样。测试用例只是他们可能期望的事情的一个例子；在这些场景中，用户可以从系统的价值中受益或传递。自动化这些测试用例可能是有用的，因为测试的工作量与代码库的大小大致成比例地增加。

BDD在围绕需求或领域存在高度不确定性的项目中工作得最好，并且人们的理解差异很大。如果你的项目已经成功了，那就坚持下去。也许您可以看看提出想法和实现它们之间的最大差距在哪里，如果BDD在这一领域对您有帮助，就使用它；否则选择其他东西。无论如何，您所做的听起来非常类似于BDD流程。