BDD/TDD vs JAD?

Question

BDD/TDD vs JAD?

6

我一直在提议我的工作场所实施行为驱动开发，通过以场景格式编写高级规范，并以一种可以想象编写测试的方式来使内容可测试。我知道，根据可测试的规范进行工作有助于提高开发人员的生产力。在我们自己的项目中，我已经能够想到几个这样的例子。然而，向业务证明这一点是困难的。这是因为我们已经有了一个联合应用程序开发（JAD）流程，其中开发人员、管理人员、用户体验和测试人员都会聚集在一起，以达成共同的需求。所以，他们问，为什么开发人员要按照测试人员创建的测试用例进行工作？这些测试用例是用于验证的，基于UX团队创建的更高级别的规范，而开发人员目前正在使用这些规范。他们说，这对开发人员已经足够了，没有必要改变规范的编写方式。他们似乎有道理。如果您已经有一个测试团队，他们的测试用例与当前提供给开发人员的更高级别的规范完全兼容，那么BDD/TDD的实际好处是什么呢？

- Jonathan

4个回答

2

这是一个很好的问题，事实上，当涉及到BDD时，这是“底线”问题。 TDD或编写单元测试的主要挑战之一是开发人员似乎从未看到更大的图片和业务角度。编写规范并生成单元测试以测试实际的“业务”场景的练习有助于开发人员提高他们的“手艺”并掌握业务视角。请查看此文章以获取更多详细信息：http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

- Anshuman

1

如果以最轻的形式思考BDD可能会有所帮助; 就是讨论特定情景。

你拥有你的用例。你拥有你的需求。现在你想验证自己对它们有一个真正好的理解。那么有人-也许是开发人员，也许是测试人员-说，“好吧。为了验证我是否理解...假设我们从<这个>开始，当用户执行<这个>时，<这个>应该发生。是这样吗？"

测试人员会说：“是的，没错。”

然后UX或分析师说：“嗯，除非存在<这个其他上下文>”。

通过就场景进行讨论，确保每个人都有共同的理解所花费的时间大大缩短了。我们通常忽略明显的情况，并关注边缘情况；新领域术语、部门之间不同的概念，与遗留系统的困难交互。

开发人员并不是真正依靠测试用例工作的。他们以需求和验收标准为基础，以与以往完全相同的方式工作。测试用例只是成为他们可能期望的事情类型的示例；用户从中受益或传递系统价值的场景。自动化这些测试用例可能很有用，因为测试的工作量大致与代码库的大小成比例增加。

BDD最适合在需求或领域存在高度不确定性，人们的理解差异很大的项目中使用。如果您的项目已经运作良好，请继续使用它。也许您可以看看想法和实施之间最大差距所在的位置，如果BDD在这个空间中对您有帮助，请使用它；否则选择其他东西。无论如何，您正在做的事情听起来与BDD过程非常相似。

- Lunivore

0

我刚看到这个问题，觉得很有趣，想发表一下自己的看法。

只有当整个团队都认为方法不可行，并且最终结果是项目失败时，该方法才会失效。

如果现有系统运作良好，那么你需要问自己：“即使我更喜欢BDD/TDD，我能否像这样工作？” 如果你的答案是否定的，并且你觉得在任何其他系统下工作都会感到不满意，那么也许这表明你的职业需要转向其他领域。如果是肯定的，那就接受这个系统。

实际上，如果是我，我会尝试接受一个新的系统。首先，这给了你一个机会去熟悉它，然后你可以更全面地评估其优缺点，并在以后提出可能的改进建议。

归根结底，一个方法论的好坏取决于它的最终结果：可工作的软件和所有利益相关者的满意度。

:-)

- S.Robins

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Don Roby · Accepted Answer

如果你想说服他们这会有所帮助，你需要做的主要是找到一个它可以解决的问题。

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

BDD 的主要优点在于改善利益相关者和开发人员之间的沟通。

如果你正在编写无法通过验证测试的代码，那么开发人员和测试人员对规范的理解不同，这意味着规范缺乏清晰性，而 BDD 肯定可以改善这种情况。

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