测试私有方法_学习单元测试，告别祈祷式编程

最新推荐文章于 2024-05-07 11:28:08 发布
最新推荐文章于 2024-05-07 11:28:08 发布
阅读量347 收藏
点赞数
文章标签： 测试私有方法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_29015899/article/details/112649788
版权

祈祷式编程

什么是祈祷式编程？这样

9698a491d34862dbd6d3cc530fe5edad.png

这样

98f3b8b54bbcf6501e6997d3aff36bba.png

用流程图表示基本就是这个样子。

3e65599302e836c5313ea3e40cf8e53b.png

推荐拜沈从文，毕竟几十年前就写出了边城。祈祷式编程有什么危害呢？

  1. 累，每次写完代码还需要再祈祷

  2. 不受控，代码运行结果主要看运气，大仙忙的时候可能保佑不了

解决这个问题有好多种方法，单元测试是其中之一。

单元测试

什么是单元测试

单元测试是由开发人员编写的，用于对软件基本单元进行测试的可执行的程序。单元(unit)是一个应用程序中最小的课测试部分。(比如一个函数，一个类

google 把测试分成小型测试、中型测试和大型测试。单元测试基本和小型测试的作用类似，但是通常也会使用mock或者stub 的方式模拟外部服务。

1e59327743ec1f2bccc3bd3e729aac76.png

理想情况下，单元测试应该是相互独立、可自动化运行的。

目的： 通常用单元测试来验证代码逻辑是否符合预期。完整可靠的单元测试是代码的安全网，可以在代码修改或重构时验证业务逻辑是否正确，提前发现代码错误，减少调试时间。设计良好的单元测试某些情况下可以比文档更能反应出代码的功能和作用。

单元测试这么多优点为什么有人不喜欢写单元测试呢？

  1. 单元测试太费时间了，对于编写单元测试不熟练的新手来说，编写单元测试可能比写代码的还费时间

  2. 单元测试运行时间太长(这通常是单元测试设计不合理或者代码可测试性较差造成的

  3. 祖传代码，看都看不懂怎么写单元测试(这个确实有点棘手。。可以考虑先给新代码加单元测试

  4. 不会写单元测试

这篇文章主要关注第四个问题，如何写单元测试。

单元测试的结构

首先看一下单元测试的结构，一个完整的单元测试主要包括Arrange-Act-Assert(3A) 三部分。

  • Arrange--准备数据

  • Act--运行代码

  • Assert--判断结果是否符合预期

比如我们要给下面这段代码(golang)加单元测试：

func Add(x, y int) int {return x + y}

单元测试代码如下：

import "testing"func TestAdd(t *testing.T) {// arrange 准备数据x, y := 1, 2// act   运行got := Add(x, y)//assert  断言if got != 3 {t.Errorf("Add() = %v, want %v", got, 3)}}

如何编写好的单元测试

什么样的单元测试才是好的单元测试呢？

先看一个例子：

package utimport ("fmt""strconv""strings")func isNumber(num string) (int, error) {num = strings.TrimSpace(num)n, err := strconv.Atoi(num)return n, err}func multiply(x string, y int) string {// 如果x 去除前后的空格后是数字，返回 数字的乘积//     比如 x="2" y=3 return "6"// 如果x 去除前后的空格后不是数字，则返回字符串的x的y倍//     比如 x="a" y=2 return "aa"num, err := isNumber(x)if err == nil {return fmt.Sprintf("%d", num*y)}result := ""for i := 0; i < y; i++ {result = fmt.Sprintf("%s%s", result, x)}return result}

测试代码可能是这个样子。

// 测试方法的名字不直观，并不能看出具体要测试什么func Test_multiply(t *testing.T) {type args struct {x stringy int}// 一个测试方法中有太多的测试用例tests := []struct {name stringargs argswant string}{{"return nil",args{"",2,},"",},{"return 2",args{"1",2,},"2",},{// 测试数据有点奇葩，不直观"return aaa",args{"aaaaaaaaaa",6,},"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",},}for _, tt := range tests {t.Run(tt.name, func(t *testing.T) {if got := multiply(tt.args.x, tt.args.y); got != tt.want {// 数据错误的时候有明确标明测试数据，期望结果和实际结果，这一点还是有用的t.Errorf("multiply() = %v, want %v", got, tt.want)}})}}

这个单元测试代码有什么问题呢？

  1. 代码比较长(这里只列出来了三个用例，实际上并没有完整覆盖全部结果)

  2. 测试方法如果出错了并不容易定位位置(三个测试数据都在一个方法，任何一个错误都会指向到同一个位置

  3. 有个测试的数据比较长，不太能直观判断测试数据是否正确

  4. 输入值并不完整，比如包含空格的数字字符串" 1" 、" 1 "、 "1 "并没有测试。

结合上面我们对单元测试目的的描述，一个好的单元测试应该满足以下几个条件：

  1. 单元测试越简单越好，一个单元测试只做一件事

  2. 对错误易于追踪，如果测试失败，错误提示应该容易帮我我们定位问题

  3. 测试函数的命名符合特定的规则 Test_{被测方法}_{输入}_{期望输出}

  4. 有用的失败消息

  5. 输入简单且能够完整运用代码的输入(包含边界值、特殊情况

比如，上边的单元测试我们改成这样：

// 测试特殊值 “空字符串”func Test_multiply_empty_returnEmpty(t *testing.T) {// 用例简单，只包含输入、执行和判断x, y, want := "", 1, ""got := multiply(x, y)if got != want {// 有效的失败消息t.Errorf("multiply() = %v, want %v", got, want)}}// 测试包含空格的数字 边界值func Test_multiply_numberWithSpace_returnNumber(t *testing.T) {x, y, want := " 2", 3, "6"got := multiply(x, y)if got != want {t.Errorf("multiply() = %v, want %v", got, want)}}// 测试正常数据func Test_multiply_number_returnNumber(t *testing.T) {x, y, want := "2", 3, "6"got := multiply(x, y)if got != want {t.Errorf("multiply() = %v, want %v", got, want)}}// 测试非数字字符func Test_multiply_String_returnString(t *testing.T) {// 输入简单的字符串就可以测试，没必要用太奇怪或者太长或者太大的数据数据x, y, want := "a", 3, "aaa"got := multiply(x, y)if got != want {t.Errorf("multiply() = %v, want %v", got, want)}}// 测试空格 边界值func Test_multiply_space_returnSpace(t *testing.T) {x, y, want := " ", 3, "   "got := multiply(x, y)if got != want {t.Errorf("multiply() = %v, want %v", got, want)}}

当然这个数据也并不完整，还可以再加入：

  • 包含空格的非数字字符

  • 数字右侧包含空格的字符串

  • 数字两侧都有空格的字符串

既然好的单元测试需要能完整的测试代码，那么有什么方法可以保证单元测试可以完整覆盖被测代码呢？

基于代码路径进行分析编写单元测试是一个方法。

单元测试路径

设计测试路径时可以使用流程图的方式来分析，拿上边multiply的例子进行分析，这段代码的路径如下：

d0cf60be248cfad7adfdfd7d920efe2b.png

当然，每个路径的测试数据并不是只有一种，比如x为前后包含空格的数字字符串这个路径中就包含三种情况：

  • 左边有空格

  • 右边有空格

  • 两边都有空格

单元测试数据

合理的设计测试数据非常重要，测试除了符合上边说的要简单直观以外还要着重考虑边界值。

设计测试数据通常是把可能的输入数据分成多个子集，然后从每个子集中选取具有代表性的数据作为测试用例。比如一段代码的作用是计算个税，我们就应该按照个税不同的等级来设计测试数据，比如：

  • 年收入0-36000部分

  • 年收入36000-144000 部分

  • 年收入144000-300000部分

  • 年收入300000-420000部分

  • ...

然后在这个子集的基础上在针对边界值做一些检查，比如36000、144000 等。

私有方法如何测试

通常情况下，如果私有方法在公有方法中有被调用，通过测试公有方法就已经可以间接测试到私有方法。

也有些私有方法写的不合理，比如私有方法没有被使用或者私有方法的功能和类的相关性不大，这个时候就建议把私有方法单独提取成新的函数或者类来测试。

外部服务如何测试

当然现实世界中的代码并不会这么简单，通常都会包含外部请求或者对于其它类的调用。在编写单元测试时，对于外部依赖我们通常使用Mock和Stub的方式来模拟外部依赖。

Mock和Stub 的区别：

4bbdd72cd69726d3fa52283f3cfb9bf1.png

  • Mock是在测试代码中创建一个模拟对象，模拟被测方法的执行。测试使用模拟对象来验证结果是否正确

29a07166c1830c2020afcedb08735d1d.png

  • Stub是在测试包中创建一个模拟方法，用于替换被测代码中的方法，断言针对被测类执行。

下面是代码示例：

Mock

实际代码：

//auth.go//假设我们有一个依赖http请求的鉴权接口type AuthService interface{    Login(username string,password string) (token string,e error)   Logout(token string) error}

Mock代码：

//auth_test.gotype authService struct {}func (auth *authService) Login (username string,password string) (string,error){return "token", nil}func (auth *authService) Logout(token string) error{    return nil}

在测试代码中使用 authService实现了AuthService 接口，这样测试时可以模拟外部的网络的请求，解除依赖。

这里使用的是golang 代码，golang 不支持重载，这样使用的问题是会产生大量重复的代码。如果是python、java等支持重载的面向对象语言，可以简单的继承父类，只重载包含外部请求的代码就可以实现Mock的需求。

Stub
package utfunc notifyUser(username string){// 如果是管理员，发送登录提醒邮件}type AuthService struct{}func (auth *AuthService) Login(username string, password string) (string, error) {notifyUser(username)return "token", nil}func (auth *AuthService) Logout(token string) error {return nil}

对于这段代码想要测试其实是比较困难的，因为Login 中调用了notifyUser，如果想测试这段代码：

  • 一个方式是使用Mock的形式，定义authService 接口，然后实现接口 TestAuthService，在 TestAuthService Login中 替换掉notifyUser。这种做法改动比较大，同时重复代码也比较多(当然如果是python java等支持重载的语言可以只重载Login接口即可。

  • 还有一种方法就是重构Login方法，把notifyUser 作为参数传入其中，这样，我们只需在测试代码中重新定义notifyUser，然后作为参数传入到Login即可模拟发送邮件提醒的功能。

第二种就是stub 的方式。

如果外部依赖是数据库，可以考虑使用内存数据库，存储测试数据来代替数据库来进行测试。通过这个例子我们也可以看到，如果想要代码容易测试，代码在设计时就应该考虑可测试性。

编写可测试代码

Writing Testable Code 中提到一个非常实用的观点：在开发时，多想想如何使得自己的代码更方便去测试。如果考虑到这些，那么通常你的代码设计也不会太差。

如果代码中出现了以下情况，那么通常是不易于测试的：

  1. 在构造函数或成员变量中出现new关键字

  2. 在构造函数或成员变量中使用static方法

  3. 在构造函数中有除了字段赋值外的其它操作

  4. 在构造函数中使用条件语句或者循环

  5. 在构造函数中没有使用builder或factory方法，而是使用object graph来构造

  6. 增加或使用初始化代码

这篇文章地址为：http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf 推荐阅读。

在公号回复 「test」 获取pdf也可以点击「阅读原文」，在文章下面参考链接查看

总结

总结一下就是编写可测试代码，使用高质量单元测试(命名清晰、功能简单、路径完整、数据可靠)保证代码质量。

参考文章

  • 搞定Go单元测试(一)——基础原理

  • Guide Writing Testable Code

  • Selective Unit Testing – Costs and Benefits

  • 版本上线拜哪个神仙比较灵验？

最后，感谢女朋友支持和包容，比❤️

也可以在公号输入以下关键字获取历史文章：公号&小程序 | 设计模式 | 并发&协程| test

25f6551807d57f7a97a0161c767a6eaf.png

References

[1] 搞定Go单元测试(一)——基础原理: https://juejin.im/post/5ce93447e51d45775746b8b0[2] Guide Writing Testable Code: http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf[3] Selective Unit Testing – Costs and Benefits: http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/[4] 版本上线拜哪个神仙比较灵验？: https://www.zhihu.com/question/52985744

逆光的温暖
关注
私有方法的单元测试
08-22 758
测试类的私有方法时可以采取两种方式： 　　1.修改方法的访问修饰符，将private修改为default或者public。（不推荐）。 　　2.在测试类中使用反射调用目标类的私有方法。（推荐）。 程序实例 　　一个计算加法的方法，是私有方法，在测试类中通过反射调用该方法进行测试. 　　PS:使用JUnit 3。 　　被测试的类： package com.men...
powermockito测试私有方法_03 增强测试: 静态、私有方法处理
weixin_34072003的博客
01-14 2281
mockito 已经很强大，能帮我们完成大部分 mock 工作，但是对于一些特殊方法来说，还是无能为力。例如，当我们使用系统获取当前时间戳的时候，可能会调用 System.currentTimeMillis()。对于这个方法来说，我们无法 mock。往往就会遇到一个有趣的现象，一些测试过了一段时间就通不过了，项目中可能有对时间进行检查的逻辑。我们有一个项目是做财务报销单，当费用产生后的几个月后报销...
对私有方法进行单元测试
08-04
NULL 博文链接：https://samjavaeye.iteye.com/blog/2026212
Java单元测试对私有方法测试
Revivedsun的专栏
12-31 4497
本文简要讲了为什么测试私有方法不是一个好的实践，其次演示了如果一定要测试私有方法，如何通过反射的方式进行测试。
JAVA单元测试怎么测试私有方法
sunglow1126的博客
02-06 951
如果你希望写个单元测试去测试你写的私有方法，直接使用类实例去调用私有方法是不行的，这里推荐使用反射来访问和调用私有方法。注意：示例中的测试方法注意要抛异常。
Spring单元测试001-如何测试私有方法
u014755679的博客
11-11 3984
Spring单元测试私有方法 @RunWith(SpringRunner.class) @SpringBootTest(classes = ServerApplication.class) public class XXXTest extends XXXServiceImpl { /** * 测试私有方法示例及说明： * 想要测试某类中的私有方法，必须通过反射。 * 反射获取私有方法有两种方式，一种是直接new对象，然后通过getClass;一种是extends要测试的
单元测试之测试私有方法
qq1458620813的博客
01-05 2231
在工作中需要保证单元测试覆盖率，但是私有方法并不能直接通过实例化接口调用，因此需要使用反射的方式。下面放代码： /** * 测试私有方法 */ @Test public void testPrivate() { try { //获得class类 Class calcutate2Class = SwiftMessageProviderImpl.class; //获取目标类的
java 单元测试 私有成员变量,单元测试时测试一个private私有方法 - - ITeye博客
weixin_26712075的博客
03-13 1592
直接上例子 待测试的类 [code="java"]public class Calculator { private int count = 0; private int add(int a, int b) { return a + b; } private void increase() { count++; } } [/code] ...单元测试时测试一个private**私有方法时，我们第一...
Spock单元测试-测试私有方法
m0_46420685的博客
03-01 1890
Spock(groovy)测试私有方法，实例. 直接点不出来，需要copy过来，进行测试 例如agencycontractQueryService.getSignDate方法，就是private方法：
Java对私有方法进行单元测试及示例
m0_46305352的博客
08-08 2716
在上述示例中，我们创建了一个MyClass类，其中有一个私有方法privateMethod。首先，我们使用getDeclaredMethod方法获取私有方法的引用，并使用setAccessible方法将其设置为可访问。然后，我们使用invoke方法调用私有方法，并传递相应的参数。然而，如果有必要测试私有方法，可以使用反射来访问和调用私有方法。需要注意的是，测试私有方法可能会违反封装原则，因为我们直接访问了类的内部实现。因此，在进行单元测试时，应优先测试公共接口，而不是直接测试私有方法。
如何测试私有方法
黄晓宇的博客
03-23 3485
由于 Java 私有方法不允许在类的外部进行访问，当我们在写 junit 测试的时候，就无法像测试其他方法一样通过对象调用的方式对 private 方法进行单独测试。但我们可以通过以下两种方式进行测试 使用反射机制 Java 反射能在运行时获得类的属性和方法，故可以通过 Java 的反射机制对私有方法进行测试，代码如下 @Test public void reflectTest() throws ...
可以测试私有方法
专业的开发者“讨论”
04-23 360
Google the phrase “should I test private methods,” and you’ll get a whole host of opinions that boil down to “no.” Fortunately, I’m here to say it’s ...
如何给一个私有方法做单元测试
热门推荐
bruce128的专栏
07-18 1万+
    给类的公有方法做单元测试，很简单，new一个对象，设好入口参数后，调用这个方法，比较期望值和实际值即可。给一个类的私有方法做单元测试，也不麻烦，先通过反射获取这个方法，然后将这个方法的可访问性强制设为true，这样的话，这个私有方法就可以被调用了。目标方法：private Double format(Double fileSize){ Double size = fileSize; s...
如何对私有方法进行测试
『地球是猿的』的博客
10-15 2309
测试中如何对私有方法进行测试： 一般情况下私有方法只能在所属类的内部进行调用，在类外则无法通过对象.方法名的方法调用私有方法。那么在平时测试中，如何测试私有方法，下面分享个人所知的两种方法，如下： 方法一： 【格式】 //调用方法格式 Object result = Deencapsulation.invoke(mockClass, methodName, parameter1, parameter2 ….); 【说明】 mockClass：该参数是需要调用方法所属的类，该类需要被mock metho
替换手机号中间4位（php，js）
mobeinight的专栏
12-24 1800
JS方法function hideMobile(num){ var mphone =num.substr(3,4); var lphone = num.replace(mphone,"****"); return lphone; } php方法 $phone=substr_replace($phone,'****',3,4);
java私有方法单元测试_Spring-boot单元测试（私有方法测试）
weixin_32643811的博客
02-25 906
Spring-boot的单元测试网上有了很多，当项目是可以使用spring-boot正常运行时，只要在测试类上添加如下配置就使用@Autowired的方式进行单元测试@RunWith(SpringJUnit4ClassRunner.class)@SpringBootTest(classes = Application.class)现在的场景时，我要测试的时这个类中的某个私有方法的功能，代码如下@R...
单元测试某个类的内部类或者某个类的私有方法
最新发布
weixin_66568937的博客
05-07 419
Method method = class.getDeclaredMethod("方法名",参数类型1.class,参数类型2.class,...);在进行单元测试时，我们往往需要直接访问某个类的内部类或者某个类的私有方法，此时正常的调用就无能为力了，因此我们可以使用反射进行调用。Class class = Class.forName("类名") 或 Class class = 类实例.getClass()method.invoke(类实例,参数1,参数2,...);使用反射调用类的私有方法。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值