TDD

TDD基于测试优先的概念。它的好处在于让人先去思考需求，再去思考实现。

如何推行TDD：1）自上而下的灌输‘TDD好’的理念；2）定期开展TDD培训，尤其在结对编程实践不在线的情况下。此时通过培训来提高TDD技能的需求就更加迫切；3）总结出一个行之有效，符合项目实际情况的TDD实践标准。4）洗脑客户。

说单元测试好和TDD好是两件事情。TDD本身的优势, 比如不会产生难以测试的代码, 比如会避免写代码到一半发现有业务上的问题不清晰导致代码要大改甚至重写, 再比如可以让测试尽量和业务要求贴合而不去和工程结构过度耦合.

测试金字塔

测试四象限

---

在“国内短期交付项目”上，对dev来说有着很多实际的困境：

1）工作量超级大，虽然可能本身的技术难度并不高，但有时候也会涉及到比较复杂的业务流程，姑且不论质量，光是把这些工作做完就不是一件轻松的事情。而由此产生的其他问题可能更严重了：因为没有时间，一些保证质量的环节被选择性的忽略掉，比如code review，重构，测试之类的，大家也会习惯性的认为没有时间做这些事情。

2）相比于其他的项目，技术方面的限制可能更多：客户对技术框架和选型的控制会更封闭（通常坑也更多，并增加了沟通成本）

3）时间紧张，根本没有时间来让团队上的成员有自我提升的机会， 卡都做不完，更别说花时间去学习和提升了。

于是大致会出现这样一个结果：为了项目能够如期交付，以牺牲代码质量为代价来赶进度。对于自动化测试来说，没时间写测试，很大程度上需要依靠QA来把控质量了。

这里涉及到一些很有意思的命题：如果不写测试，是不是可以提升开发进度或者说开发效率？由此带来的质量牺牲是否划算？   

我们先来看第一个命题，我相信大多数人会支持不写测试（或者说不用TDD）开发速度肯定会更快，理由很简单，因为写测试本身也是在写代码，是需要成本的。而要衡量这个成本有多大，需要从两方面考虑：一个就是测试框架的能效比，简而言之就是写测试是否容易，是否运行迅速，如果写起来很麻烦，或者说写了之后每次跑测试需要很久，那么很显然能效比不大高。理想的状态应该是，我们能够很容易的编写测试，而且测试的速度应该比较快，不至于跑测试的时候需要去喝杯咖啡。另一个方面就是开发人员对测试框架的熟悉程度，越是熟悉那么写起来也越得心应手。

而通常认为写测试会降低开发速度，其实建立在一个前提上，就是使用其他方式的验证（比如说把系统跑起来人工去试）会比通过测试去验证更高效。但是往往我们做的卡多多少少都会有很多的场景需要测试，尤其是比较复杂的业务卡，对应的代码也有很多内容，而我们通过人工的方式去验证，实际上不会去考虑太多的场景。那么，如果dev自己没有去验证这些，这部分工作就要单纯依靠QA来完成了。

姑且不考虑代码修改所需要的回归测试的成本，单纯只说开发一个功能的时候，我认为很多时候其实通过自动化测试的方式更加迅速。因为这些自动化测试可以更早，不需要等到所有功能都完成之后才能进行，而且很容易进行隔离，不必要等待一些环境或者其他功能的完成。

所以从这个角度来说，我倾向于认为通过自动化测试的方式来开发反而违背常理的更加迅速。

对于大多数人来说一定是反反复复修改，反反复复测试；当然我相信有人可以很快写完可以work的代码，但如果你对代码对自己有更高的要求，一定会不满足单纯work而已吧？重构是必然的，而重构的前提是得有测试撒。

从另一个层面来说，我们抛开质量的一个前提忽略测试，主要是因为工期紧张。但实际上，上线结束之后通常项目并不会结束，可能会有下一期，也可能会给到其他人维护。所以从这个角度而言，所谓“短期国内交付”并不十分准确，这些技术债，最终可能都是自己来还。

软件交付不是短跑，跑完之后留下一地鸡毛。你写下的每一行代码后续都可能是需要他人维护的。