我一直在提议我的工作场所通过以场景格式编写高级规范来实现行为驱动开发,并且可以想象为它编写测试.
我知道,对检验的规范工作趋于提高开发人员的生产力.我已经可以想到几个例子,我们自己的项目就是这种情况.
然而,很难向业务证明这一点的价值.
这是因为我们已经建立了联合应用程序开发(JAD)流程,开发人员,管理人员,用户体验和测试人员都聚在一起就一组共同的需求达成一致.
因此,他们问,开发人员为什么要反对测试人员创建的测试用例？这些是用于验证的,并且基于UX团队创建的更高级别的规范,开发人员目前正在开发这些规范.
他们说,这对开发人员来说已经足够了,而且无需改变规范的编写方式.
他们似乎有一点意义.
BDD/TDD的实际好处是什么,如果您已经有一个测试团队的测试用例与当前给开发人员的更高级别的规范完全兼容？
如果你想让他们相信这会有所帮助，你需要做的主要事情就是确定它可以解决的问题。
您认为您的情况中发生了什么事情会有所改善？
BDD 的主要好处是改善利益相关者和开发人员之间的沟通。
如果您生成的代码未通过这些验证测试，那么开发人员对您的规范的理解与测试人员不同，这意味着规范缺乏清晰度，而 BDD 肯定可以改善这种情况。
作为开发人员，您可以在不更改整个团队流程的情况下处理流程的某些部分。如果您专注于单元测试级别并进行传统的测试驱动开发，这可能会提高您的工作效率。