测试驱动开发，TDD。
测试在前，实现在后；测试代码决定业务代码；关注点分离；红绿循环……这都是我们耳熟能详的对TDD的描述。
TDD固然有很多的优点，但遵循TDD的实践同时也提高了对程序员的要求。
在网上随便一搜，TDD的优缺点随处都是。讲解如何实践TDD的优秀文章也大有所在。
而这次我是想结合自己对TDD的理解，和在项目上的实践，说说我自己的TDD是怎么样的。
只有四个多月的实践，肯定还有很多欠缺。但是我相信未来我自己肯定还会写一个新的《我的TDD》，看看那时的我和现在的我有什么不一样的理解。
那些基于ATDD、UTDD的理论就不在这里详细讨论了，上面的刘冉老师我觉得已经讲得很清楚了。
这次我主要是想结合我自己的个人经历，说说我在这几个月对TDD的实践以及自己对TDD理解的变化。
在阐述我自己的TDD实践之前，我想要强调的是：
TDD是实践，更是一种思维
不是因为我们在代码中先写测试，后写实现，就是TDD了；也不是因为我们没有严格遵循先有测试后有业务逻辑，就不是TDD了。
**TDD首先带出的应该是思维，一种关注点分离的思维，一种分层、分支思维；而后将我们的所想编码反应在测试上，最后根据测试——我们思维的具象体现，编写真正的业务逻辑代码。这就是我理解的一个完整的TDD。**在刘冉老师的文章里也有类似的例子。
下面的个人理解，很多都是基于上面的理解去发散的。
首先，是一个简化版的我自己理解的红绿循环。这个示意图是建立在具体项目上的。我所实践的架构采用六边形架构。