如何写好单元测试(php程序猿)

布满荆棘的人生 2022-04-04 13:37 277阅读 0赞

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

百度经验地址：[**http://jingyan.baidu.com/article/597a0643239f36312b524386.html**][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)"

参考文献：

[https://www.jianshu.com/p/1cb94e6508b8][https_www.jianshu.com_p_1cb94e6508b8]

[https_github.com_qq1060656096_phpunit-test]: https://link.jianshu.com?t=https://github.com/qq1060656096/phpunit-test
[http_jingyan.baidu.com_article_597a0643239f36312b524386.html]: https://link.jianshu.com?t=http://jingyan.baidu.com/article/597a0643239f36312b524386.html
[https_www.jianshu.com_p_1cb94e6508b8]: https://www.jianshu.com/p/1cb94e6508b8