TDD的实践人员是谁？QA在编写自动化测试的时候如何进行TDD？

TDD，测试驱动开发，通常如果不加限定，是指狭义的测试驱动开发，有的人也称为单元测试，但这个单元也不是特指对一个类或者一个方法这么简单的定义，而是为了跟像验收测试这种更加关注在端到端功能的测试区分开，也跟那种关注多个系统集成的测试进行区分。

它更关注程序员在开发阶段的质量内建，关注的代码粒度通常更小。什么意思呢？比如你是一名程序员，你编写的代码通常是由很多细粒度的代码层、模块、类、方法组成，你应该为这些细粒度代码的质量负责，怎么负责呢？极限的做法，你应该在代码生产出来通时就可以自信地说功能是可靠的。要做到这一点，你就需要持续对这些代码进行测试，TDD就是一项不错的实践。

同时为了快速和持续获得反馈，你就需要一种更细粒度、更容易编写且更容易运行的测试，所以，在开发质量内建阶段，TDD所编写的测试通常粒度更小。保障了一个个小的模块功能正确，也意味着朝着端到端的客户验收测试目标更加靠近了。

如果你是一名QA，如果你编写自动化测试聚焦在客户验收上（客户验收测试），你也可以采用TDD，这就是广义上的TDD了。你在开始前同样需要对业务场景Tasking，穷尽所有的场景和容易被程序员忽略的场景。然后从写第一个测试开始，只不过你使用的测试框架可能有所不同，关注的粒度更大。在这个TDD循环中，定义测试的是客户，编写测试的是你，让测试通过的是开发人员。由于是端到端的客户验收测试，让测试通过的时间周期会较长，这也是可以接受的。