最近在组织项目成员的能力提升，不可避免的就进入了TDD这个话题。对于TDD，已经成为很多公司员工入职的专业知识培训课程。网上关于TDD的各种文章和讨论也很多，但是感觉大家都是望文生义，都是先写测试用例，再写代码。
可能有人会说TDD就是“Test Driven Development”，就是测试驱动开发。就是写测试用例，然后再写代码。我承认，书里是这么写的。大家也是这么理解，然后去实践的。实际效果如何呢，就我了解的情况，大家对这个都很纠结。很多都在说，我先写几行代码，然后再写用例为啥就不行了呢？难道真是缺少仪式感吗？
那么我先说说，我最近的思考。TDD方式，实际上是关注点驱动开发，或者说规则驱动开发。我要实现一个关注点/规则，我就先一条用例来验证这个关注点/规则，然后去完成这个关注点/规则的代码。如果按照这个思路去思考，我每次实现一个关注点/规则，我先写用例后写代码，或者先写代码再写用例。每次都是围绕着一个关注点/规则，是否先后顺序就显得不那么重要了。关键是每次聚焦于一个关注点/规则，有测试用例保证这个关注点/规则的准确性。那么就可以放心的去实现下一个关注点/规则，并且保证整个功能的准确了。
以上是我对于TDD的最新理解和思考。各位看过后是否也对TDD也有了新的理解了呢？
网友评论