1：传统的编码方法
它的特点如下
2.1：编写一个失败的单元测试，来证明产品代码中存在缺陷，来进行修复这个缺陷
比喻我们要实现一个用户的添加方法User.Add，我们就会写一个测试方法来验证这个User.Add。当然在最初的测试肯定会失败，因为我们根本就没有
编写User.Add的编码所以运行失败以后我们就会去实现这个编码，直到通过为止
2.2：编写符合测试预期的代码，是测试通过
2.3：重构代码
第一次我们的编码肯定是为了完成功能可能可读性，规范效率还不是很好，所以我们会不停的重构自己代码直到编写出好的编码。
3：单元测试的优点:
3.1：快速找出项目中存在的bug
因为在编码中我们自己手动测试不具有普遍性，比喻验证null，没有加入判断，很多代码就是天马行空，这样在其他人测试之后到处都是bug，不停反复的修改就是改不完，开始加班加班
导致大家士气低落。等产品上线以后每天都要应付各种bug非常疼苦。所以早期加入单元测试这样一来就会减少大多这样的麻烦
3.2：代码重构
重构我们都不陌生，为什么重构呢，因为不重构实在是没法看了，或是命名规则，或是方法过长，或是效率低下等等，但是如果我们不加入单元测试，你这么一重构，又要手动点着去测试
项目提交之后又出现新的bug，可能和你合作人就会抱怨，天天重构，现在出了问题吧。团队就会出现抱怨，最后的后果大家都不去重构代码，明知道那不对。所以单元测试在重构占着很重的地位
优点是个人观点。熟悉TDD的可以给建议
以上图是参考单元测试的艺术。
