我的TDD感悟（二）--TDD的“红”

在我的TDD感悟（一）中，说到了测试用例的重要性。当完成了测试用例的编写，我们可以进入到TDD中的“红”，也就是单元测试代码的编写。

测试用例和测试代码

有了测试用例文档，那么测试代码就容易编写多了。有了测试用例相当于定了一个测试目标，这个时候可以先评估测试用例，看哪个测试用例是最重要的。优先度最高的用例，可以优先挑选出来先实现

测试代码要尽可能的简单

单元测试一般采用3A模式（Arrange，Act，Assert）。代码量不宜太多。单元测试本身也是代码，测试代码本身不会再被验证是否正确。因此测试代码越是简单，就越容易判断测试代码是否正确。否则一旦执行的时候，当测试条变为红色的时候，不好排查是测试代码有问题， 还是被测试代码有问题。增加了排查难度

在写测试代码的时候需要考虑以下几个点：

• 被测试的类名是什么（这个时候就需要考虑类的职责问题了）
• 被测试的API的名字，参数和返回值（这个时候考虑的是功能点的设计和API的易测性）
• 最容易编写的测试代码是调用一个API，然后通过API的返回值，调用Assert进行验证。所以被测试的API在设计的过程中，如果能符合幂等性，那么测试会更容易做一些。且这个API日后的可维护性也会增强，并且比较容易保证质量。

这里主要还是强调类API的设计， 虽然大脑会不自觉的考虑到具体算法。但是毕竟没有真正的写代码，所以还不会陷入到代码细节里。大脑还是比较容易聚焦于设计上

如果一个测试代码需要多久写完

• TDD里的测试代码不一定是一口气写完的。有些会根据后续的算法和重构，进行相应的修改
• 一般TDD里的一个循环（红->绿->重构）的周期不要太长，2~3分钟为一个周期会合适些，这样在出问题的时候，比较容易缩小范围，缩短排查的时间。所以当我们把API的类和函数写完后，剩下的测试代码编写应该要在短时间内就能完成
• 如果单元测试代码需要写很久，要有非常多的前置条件满足，才能测试对应的API。或者在验证结果的正确性时，需要很多代码才有办法验证（比如要获得某个全局变量才能验证等等）这个时候我们需要考虑：我们的测试力度是否太大了（是否变成了集成测试），或者我们的API设计的太复杂了，不符合幂等性

综上所述，单元测试代码越简单，也会让程序员愿意往下接着按TDD的方式写代码。否则容易出现的一个现象就是：放弃