phpunit单元测试(demo):https://github.com/qq1060656096/phpunit-test

百度经验地址：http://jingyan.baidu.com/article/597a0643239f36312b524386.html

很多没写个单元测试的朋友，总觉得单元测试很难,还增加了工作了，或者把单元测试环境搭好了,也写了很多单元测试,越写越累,感觉代码质量没提高,工作量反而提高很多。我们一起来学习下如何写好单元测试。

我们分以下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. 单元测试与集成测试区别？

测试粒度不同:单元测试是程序最小的单元,而集成测试是一个功能，一组功能或者整个系统上

单元测试：程序的最小单元。

集成测试：也叫组装测试或联合测试，是在单元测试的基础上，把所有模块按系统设计要求组装成功能或者系统，实际中程序单元，测试通过了，不能保证程序组装也能正常的工作，程序某些在局部反应不出问题，很有可能在全局或者特殊场景下暴露出问题。

单元测试和集成测试很容易混为一谈：因为单元测试和集成测试可以试用相同的工具和框架编写。

3. 先写代码还是先写单元测试？

编码前，要先写测试，很多没有写过单元测试的朋友会想，代码都没有，连测试的对象都没有，我怎么写单元测试？

1. 我们可以通过先话流程图，写伪代码或者建模来解决这个问题，这样让我们站在用户的角色去开发，尽早的发现问题

2. 避免我们开发完了，某个功能模块遗漏了的情况。

3. 这样开发出来的程序扩展性、维护性很容易理解。

4. 谁来编写单元测试？

单元测试一般由开发员自己些，但是我们自己对自己的代码编写单元测试的情况下，习惯性的往理想情况下编写，开发员最好不要针对自己的代码编写单元测试。应该有其他开发编写，这样减少了bug也提高了开发的水平。

5. 如何避免无用的测试？

1. 只写必要的测试

编写自己觉得不靠谱的代码，例如业务很复杂自己没有吃透，以前没有写过，感觉会产生无法预料的结果。

2. 只写关键的测试

有时候必要的测试我们些不出来，也没有人知道，我们只能勉强跳过。但是关键性的测试不能跳过，关键性测试就是:你写的代码的核心洛基。如果你不知道怎么处理，你知道要保证最终要的那条路线是可以走通的，将来重构的时候，这条路线能确保你不会茫然。

3. 无用的测试

3.1 不要去测试开发语言的标准库和核心库,因为这些代码都是久经考验过得。虽然这些会出现小概率的错误。（如果你确定是开发语言的标准库或者核心库的问题，你应该测试标准库和核心库，因为它们都带有完整的测试用例）

3.2 不要去测试基础框架和工具方法和外部依赖的有效性,当你遇到这种问题，你应该打桩"mock"。

3.3 你只见过它测试通过，没有见过它测试失败，可能这种测试从头到尾都没测试任何代码，我们应该手动破坏代码，以确保帧的覆盖到了目标代码。

6. 测试代码覆盖率？

我们应该忽略代码覆盖率：就算覆盖率达到100%，和"靠谱"的代码肯能有天壤之别，问题就在于有些公司把代码覆盖率作为考核的标准，这就让开发很容易就演变成"追求100%代码覆盖率"，然后无所不用，连开发都不懂，那就更悲剧了，一群人对着水分极大的代码，然后对着"100%代码覆盖率"乐得合不弄嘴，想想都难受想哭。

测试中的仿件"mock"或者我们说的打桩？

有时候对被测试的系统进行测试很困难，因为它依赖无法在测试环境中使用的对象、组件、API或者它们不可用。在这种情况下，我们确保测试系统的内部行为有更多的控制性和可见性，我们可以使用仿件"mock"或者打桩。

7. 什么情况下使用"仿件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)"