你的BDD或者TDD真的香吗？

定义

BDD

• BDD，指行为驱动开发。在软件工程实践中，由用户预期行为为主导，系统设计人员细化行为，并将拆解的行为构建成具体的功能，由开发人员将功能模块化，测试人员根据功能编写测试用例。这样的描述我们可以看出BDD更加侧重了团队协作，最后会由开发和测试一同验证用户行为的最终交付产物。BDD是在TDD和DDD的不断实践中应运而生的产物，以用户故事（User Story）为主线进行项目开发的推进，大大提高了团队协作效率和产品还原度。

TDD

• TDD，指测试驱动开发。以测试人员编制的测试用例为软件工程推动的主动力，研发人员根据测试用例率先完成单元测试的开发。显然这种模式会让测试人员更加深入的参与到软件开发的整个生命周期之中，相应的对测试人员提出了更高的要求。软件开发前的单元测试将贯穿整个开发周期，并且可以在开发、重构下重复使用来验证功能代码。这样的模式让开发人员更加安心的追加新功能或者进行优化重构，每次编码后都可以运行完整的单元测试用例来验证是否影响到已有功能，大大减少了开发过程中不必要的错误。

最佳实践

       在项目实践中，TDD对于开发人员来说更加简洁明了，在项目的优化重构上更是突显其效率上的优势。研发人员可以更加专注于代码开发上，每次重构修改代码，只需要重新执行原先的单元测试用例即可。而BDD对于开发人员来说，不仅仅是直接面向于接口功能，BDD的模式将开发人员更加拉近用户需求。通过解析用户最原始的需求，编制出逻辑清晰的用户故事。这种模式，对于整个项目周期的参与人员来说，都可以将用户故事作为沟通的基石。但是随着项目和产品的演进，单一的使用TDD或者BDD都存在各自相对的劣势，TDD在团队协作上存在缺陷，侧重细化测试用例，弱化了产品或项目的全局业务逻辑，对于项目过程中的测试人员、产品经理、项目经理并不那么友好。而BDD虽然解决了团队沟通的问题，在业务建模上提供便捷，但是在重构优化上却比TDD要付出更多的成本。不管是TDD还是BDD，对于项目的干系人而言，真正能提高效率发挥最大作用才是王道。将TDD与BDD有效结合，相互补充，相互辅助才可以充分发挥出两者实践中的优势。项目参与人员先通过BDD设计出完备的用户故事，团队成员以确定的用户故事为主线，基于用户故事进行测试用例编制，将TDD的模式局限于开发人员和测试人员之间，对于项目整体的沟通仍旧采用主线模式。开发人员和测试人员以细化的测试用例，明确约束功能和接口的开发，对开发、重构后的回归测试提供强制约束。在项目的整个生命周期，BDD和TDD会穿插进行，BDD把控主线，TDD专注局部，这样的BTDD将是一种更加高效、便捷的模式，大家也不妨亲自在项目管理中试试。