BDD/TDD对JAD？

Question

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

我确实知道，违背可测试规范往往会提高开发人员的生产力。我已经想出了几个例子，在我们自己的项目中就是这样。

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

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

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

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

他们似乎是有道理的。

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

Answer 1

您可能会被推退，因为您正在将这两者视为相互排斥的(并因此与您的团队进行交流)，而它们不是。

你所拥有的是一个很好的模型。如果“放弃”起作用的东西，那将是一个错误。幸运的是，TDD正是编写测试规范的时候。这并不意味着测试人员编写产品规格。

如果您想要做TDD，您的产品规格应该按照现在的方式编写。然后测试人员应该根据这些规范编写测试用例。然后，您的开发人员为这些测试用例开发传递代码(他们不需要对产品规范视而不见--尽管您的团队是新手，但您的测试用例可能不足以帮助说明产品规范)。

这不应该让你的团队感到不舒服。事实上，它应该给管理层和您的UX团队带来更多的安慰-- 1)首先知道他们的规范在代码编写之前已经过验证，并且在可测试的场景中是有意义的；2)知道编写的代码实际上经过了很好的测试。(这方面的好处已经得到了回答)。

我在一个团队工作了几年，这个团队拥有您描述的确切流程(您称之为JAD)，并逐渐添加了TDD，对于我们来说，结合这两个概念肯定是最好的方法。

Answer 2

TDD与QA测试或创建规范没有什么关系。TDD是一种编程过程风格，它缩小了对什么以及如何开发的关注，给出了一个规范。最终的结果是“刚好足够”代码来通过测试。这确保了两件事。首先，您的应用程序是100%测试的规格，因为开发人员了解他们。其次，更重要的是，使用这组单元测试，您现在可以在处理下一件事情时自信地重构。

QA与确保系统实现用户期望的功能一样重要，也在于确保代码不受bug的影响。

Answer 3

老实说，我觉得这些多字母缩写词简单地描述了整个开发过程的一个特定子集。这是很好的形式，以便他们可以谈论，但现实是，在我看来，成功的软件组织实现了他们所有的一些混合。不过，我认为JAD的正式实现是垃圾，因为委员会的设计是无效的。它肯定不会在较大的组织中起作用。

为了更具体地回答您的问题，我认为在功能需求文档中有很大的误解空间。特别是在管理方面。我们通过在需求文档中包含两个组件来解决这一问题。

1. 用简单的英语实现的高层次的要求，通常没有具体的细节。具体描述了典型的用例。用这种方式编写的要求往往更容易被诸如销售或营销这样的技术类型所消化。我把这叫做BDD
2. 功能需求。这些都是明确定义的需求，可以根据这些需求进行测试。通常，我们的QA部门和一些时候支持是这些的目标受众。我称之为TDD。

因此，如果必须为BDD辩护，我认为它限制了“管理层”准确理解产品的可能性。