很多没习惯写单元测试的开发者，总觉得单元测试很难，还增加了工作了，或者把单元测试环境搭好了，也写了很多单元测试，越写越累，感觉代码质量没提高，工作量反而提高很多。我们一起来学习下为什么要写单元测试，以及如何写好单元测试。
我们分以下7个小点来讲解:
1.为什么要些单元测试？
2. 单元测试与集成测试的区别？
3. 先些代码还是先写单元测试？
4. 谁来编写单元测试 ?
5. 如何避免无用的测试 ？
6. 测试代码覆盖率？
7. 单元测试中的"mock仿件"或者我们说的打桩？
1、为什么要些单元测试？
目的：
1. 提高软件质量
2. 减少bug
3. 减少重复的工作
4. 安全的重构已有的代码
5. 让开发者对程序稳定性更有信心
重要性：
1. 运行单元测试是为了保证代码的行为和我们期望的结果一致。
2. 写单元测试会增加代码工作量,同时也节约了bug修复时间。
3. 如果没有写单元测试，没有发现bug的情况下，程序在测试人员测试的时候才发现问题或者在线上环境(正式环境)用户使用才发现问题，在去修复bug。开发会花大量的精力去修复bug和走部署流程，测试也会花大量的时间去做了重复的测试。很不划算。
4. 在线上某些场景下bug导致大量的数据丢失,需要花很大精力去修复数据，或者根本没办修复数据导致严重的后果。
2、单元测试与集成测试区别？
测试粒度不同: 单元测试是程序最小的单元,而集成测试是一个功能，一组功能或者整个系统上
单元测试：程序的最小单元。
集成测试：也叫组装测试或联合测试，是在单元测试的基础上，把所有模块按系统设计要求组装成功能或者系统，实际中程序单元，测试通过了，不能保证程序组装也能正常的工作，程序某些在局部反应不出问题，很有可能在全局或者特殊场景下暴露出问题。
单元测试和集成测试很容易混为一谈：因为单元测试和集成测试可以试用相同的工具和框架编写。
先写代码还是先写单元测试？
编码前，要先写测试，很多没有写过单元测试的朋友会想，代码都没有，连测试的对象都没有，我怎么写单元测试？
1. 我们可以通过先话流程图，写伪代码或者建模来解决这个问题，这样让我们站在用户的角色去开发，尽早的发现问题
2. 避免我们开发完了，某个功能模块遗漏了的情况。
3. 这样开发出来的程序扩展性、维护性很容易理解。
4、谁来编写单元测试？
单元测试一般由开发员自己些，但是我们自己对自己的代码编写单元测试的情况下，习惯性的往理想情况下编写，开发员最好不要针对自己的代码编写单元测试。应该有其他开发编写，这样减少了bug也提高了开发的水平。
如何避免无用的测试？
1. 只写必要的测试
编写自己觉得不靠谱的代码，例如业务很复杂自己没有吃透，以前没有写过，感觉会产生无法预料的结果。
2. 只写关键的测试
有时候必要的测试我们些不出来，也没有人知道，我们只能勉强跳过。但是关键性的测试不能跳过，关键性测试就是:你写的代码的核心洛基。如果你不知道怎么处理，你知道要保证最终要的那条路线是可以走通的，将来重构的时候，这条路线能确保你不会茫然。
3. 无用的测试
3.1 不要去测试开发语言的标准库和核心库,因为这些代码都是久经考验过得。虽然这些会出现小概率的错误。（如果你确定是开发语言的标准库或者核心库的问题，你应该测试标准库和核心库，因为它们都带有完整的测试用例）
3.2 不要去测试基础框架和工具方法和外部依赖的有效性,当你遇到这种问题，你应该打桩"mock"。
3.3 你只见过它测试通过，没有见过它测试失败，可能这种测试从头到尾都没测试任何代码，我们应该手动破坏代码，以确保帧的覆盖到了目标代码。
5、测试代码覆盖率？
我们应该忽略代码覆盖率：就算覆盖率达到100%，和"靠谱"的代码肯能有天壤之别，问题就在于有些公司把代码覆盖率作为考核的标准，这就让开发很容易就演变成"追求100%代码覆盖率"，然后无所不用，连开发都不懂，那就更悲剧了，一群人对着水分极大的代码，然后对着"100%代码覆盖率"乐得合不弄嘴，想想都难受想哭。
测试中的仿件"mock"或者我们说的打桩？
有时候对被测试的系统进行测试很困难，因为它依赖无法在测试环境中使用的对象、组件、API或者它们不可用。在这种情况下，我们确保测试系统的内部行为有更多的控制性和可见性，我们可以使用仿件"mock"或者打桩。
什么情况下使用"仿件mock、桩件stubs" ?
1. 外部依赖不存在。
2. 外部依赖不会返回测试需要的结果，或者它有不良的副作用。
3. 如果外部依赖更变，会导致我们的测试失败。
我们来看一个打桩示例：
1. 我们在编写单元测试购物车"Cart"类，依赖产品类"Product"和用户类"User"。
2. 依赖产品类"Product"和用户类"User"已经测试过了。
3. 依赖的产品类"Product"和用户类"User"是由他人开发的。
示例问题：
1. 产品类"Product"和用户类"User"一旦出现问题，不会让我们误以为购物车类"Cart"出了问题。
2. 不用为了创造很多前置条件，才能做出断言。（如果这样你应该把它放到集成测试）。
3. 在测试购物车时，我们应该避免使用"new Cart($userId, $productId, $quantity)"这种方式，这样会出现程序中很多地方都去做了重复的查询，并且影响程序的执行效率，更不利于打桩，我们应该使用这种方式"new Cart(User $user, Product $product, $quantity)"
作者：长风Drupal开发 赵威杰
