Go项目的测试代码3（测试替身Test Double）
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Go项目的测试代码3（测试替身Test Double），小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3063字，纯文字阅读大概需要5分钟。
内容图文
上一篇文章介绍了项目中测试代码的写法。
Go项目的测试代码2（项目运用）
这里简单的共享一下测试替身。
当我们写测试代码的时候，经常遇到一个问题。
跟别的模块或服务有依赖性，可是功能还没开发完。
或是因为各种原因(安全，白名单，内网等等…)开发环境里无法调用相应的模块。
这时候我们应该如何去写测试代码？
因此测试替身Test Double出现了。 其功能和名字一样，做替身。
测试替身Test Double的分以下类型。 Dummy, Stub, Fake, Spy, Mock
Dummy
最简单、最原始的测试替身型别。Dummy 没有实作，最常用于需要参数值但不使用它的情况。
Null 可视为是 Dummy，但真的 Dummy 是接口或基类的衍生，且完全不包含实作。
Stub
Dummy 的上一级，Stub 是接口或基类的最低限度实作。
会传回 Void 的方法通常完全不包含实作，而会传回值的方法通常会传回硬式编码的值。
Spy
测试 Spy 类似 Stub，但除了提供客户端可叫用成员的实例，
Spy 还会记录叫用了哪些成员，好让单元测试验证所叫用的成员是否符合预期。
Fake
Fake 包含更复杂的实作，通常涉及所继承型别之不同成员之间的互动。
虽然不是完整的生产实作，但 Fake 与生产实作很相似，尽管它会采取一些快捷方式。
Mock
Mock 是由 Mock 链接库动态建立 (其他通常是由测试开发人员使用程序代码来产生)。
测试开发人员永远看不到实作接口或基类的实际程序代码，但是可以设定 Mock 以提供传回值、预期要叫用的特定成员…等等。
视其中的设定而定，Mock 的行为可能会像 Dummy、Stub 或 Spy。
以上是网上流行的概念和理论。
我在项目中的运用
我开发的是在企业微信中的应用，所以需要调用企业微信的API，
用过的人应该知道，这需要登记可信域名(简单的说不能本地调用，只能发布到服务器才能调用)。
也可以用第三方工具去模拟调试，但是这么做感觉很不方便。而且Debug也相当麻烦。
我是这么处理的。
项目初期(一阶段)
直接写硬代码hardcode。
一般我们都会说尽量避免写硬代码hardcode,
但是项目初期我建议大家这么写。
为什么？ 其实很简单。
初期我们应该把所有的精力放在自己模块的功能和稳定性。
没必要在别人的接口里耗精力, 甚至去考虑怎么和其他模块做联动。
例子：
var key stringif config.AppEnv == "test" || config.AppEnv == "dev" { //测试或是开发环境的时候直接赋值
key = "23836728366"
} else {
key, err = (Login{}).GetKeyForLogin(ctx, code) //实际调用的接口写在这里if err != nil {
return nil, err
}
}
项目中期(二阶段)
硬代码hardcode改写函数function。
可以写根据参数或设定返回不同值的方法。满足不同场景下有不同返回值的需求。
例子：
var key stringif config.AppEnv == "test" || config.AppEnv == "dev" {
key = GetKeyForLoginForTest(ctx, code) //测试或是开发环境的时候直接赋值
} else {
key, err = (Login{}).GetKeyForLogin(ctx, code) //实际调用的接口写在这里if err != nil {
return nil, err
}
}
func GetKeyForLoginForTest(ctx context.Context, code string) string { var key stringswitch code { case"code1": key = "key1"case"code2": key = "key2"case : ...... default: key = "key3" } return key }
项目后期(三阶段)
函数function升类或package。
这个阶段是可选项，因为这里开始需要耗精力去管理自己的“替身”了。
根据自己的实际情况来决定要不要这么做。
例子：
type LoginTest interface { GetKeyForLoginForTest(ctx context.Context, code string) string } type SellerTest struct { } func (SellerTest) GetKeyForLoginForTest(ctx context.Context, code string) string { //销售员业务处理...return"SellerKey" } type ManagerTest struct { } func (ManagerTest) GetKeyForLoginForTest(ctx context.Context, code string) string { //业务处理...return"ManagerKey" } func BuildManagedObject(ctx context.Context, condition string) string { switch condition { case"condition1": return SellerTest{} case"condition2": return ManagerTest{} case : ...... default: return SellerTest{} } }
var key stringif config.AppEnv == "test" || config.AppEnv == "dev" {
var loginTest LoginTest
loginTest = BuildManagedObject(condition)
key = loginTest.GetKeyForLoginForTest(ctx, code) //测试或是开发环境的时候直接赋值
} else {
key, err = (Login{}).GetKeyForLogin(ctx, code) //实际调用的接口写在这里if err != nil {
return nil, err
}
}
这么做其实能解决大部分的问题。
不知道我做的项目小或范围小，总之还没有碰到过用以上方式不能解决的问题。有什么不太恰当的部分随时欢迎指正。
组员不愿意写测试代码而找借口的时候你可以这么说了…^^
组员：这次项目依赖性很高, 其他模块的功能还没完善, 开发都很麻烦别说写测试代码了。
我：你用过测试替身吗？可以很简单的解决这些问题。
原文：https://www.cnblogs.com/limingxie/p/9131948.html
内容总结
以上是互联网集市为您收集整理的Go项目的测试代码3（测试替身Test Double）全部内容，希望文章能够帮你解决Go项目的测试代码3（测试替身Test Double）所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。