1. 前言
说实话,除了测试要求,我实在不知道写单元测试有什么意义,一个函数50行代码,有多种参数组合,为了测试这些条件,需要编写测试用例,写完的测试用例比需要测试的函数还长。也就是说,除了写函数,还要写测试用例,增加的工作量不是一点点。特别是,需求经常变化,维护功能性代码本身就需要很大的工作量,还怎么记得要同步更新测试用例呢?很多程序员连基本的注释都做不好,还谈什么单元测试。
我不喜欢测试用例的另外一个原因,就是我们目前的代码习惯是,除了基本的函数文档外,还会在函数文档中写上一些测试用的数据,这些数据既是写代码时候的测试数据,也算是就针对这些数据写代码吧。
相比之下,我们的文档和注释已经很好了,有些人会说,良好的命名和代码结构就能说明函数功能。我想说的是,啊呸
,除了简单到不行的功能,否则永远是看注释来的方便,注释一行字,说明了业务功能和处理逻辑,而看代码需要10行,还需要花心思理解其中的逻辑运算。为什么那么多人喜欢造轮子,就是看不懂逻辑,但是知道要干什么,没办法,自己搞一套咯。
但是项目有要求,要有单元测试。没办法,请教测试组的同时有没有办法可以自动生成单元测试,得到的回答是,你好懒啊。
2. 原理
用python的同学都是到函数文档的个什么东西,没错,我的想法就是在函数文档中写单元测试,另外用脚本提取函数文档,生成单元测试文件,岂不快哉。
# -*- coding: utf-8 -*-
"""
python模块的第一个注释,就是模块文档,比如这一行
"""
def other_func(a,b):
"""函数的第一个注释,就是函数文档,比如这一行,当然也可以是多行"""
pass
class maths():
"""类的第一个注释,就是类文档,比如这一行"""
def __init__(self):
pass
def add(self, a,b):
"""类方法的第一个注释,就是类方法的文档,比如这一行"""
pass
现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:691998057【暗号:csdn999】
3. 单元测试的简单类型
单元测试的简单类型,包含以下几个: - 测试一个简单函数,没有外部依赖 - 测试一个简单函数,包含外部函数依赖 - 测试一个简单函数,包含外部类依赖 - 测试一个类方法,包含外部函数依赖 - 测试一个类方法,包含外部类依赖
为什么特别说明包含外部依赖呢?因为我们写代码的时候,外部接口依赖说不定还没有开始开发呢,而且开发了也不一定正确对吧,此时我们需要假设外部依赖已经完成并且是正确的,它会返回我们预期的值,这样我们就可以接着往下写代码了。
这个假设,就是 mock
,很有意思的东西。为什么简单说明,请看下面的示例,我们需要调用外部http接口,但是http接口没有完成,此时就假设它已经完成,并且返回值是10:
def get_http(url):
return request(url) # 正常的代码,返回request的值
#--->
def get_http(url):
return 10 # 测试时候,我们假设它返回10
在正式代码中肯定是写 request(url)
,但是在单元测试的代码中,我们可以使用mock
使它返回10.
@mock.patch('request')
def get_http(mock_request):
mock_request.return_value = 10
return request(url) # 此时返回值是10,因为我们用mock做了替换
4. 一个简单的例子
下面的一段代码是单元测试写法,包含了mock函数和mock类方法:
import unittest
from unittest import mock
from unittest.pyauto_unittest_test import maths, func_add # 导入需要测试的函数和类
class Test_pyauto_unittest_test(unittest.TestCase):
def setUp(self):
pass
def tearDown(self):
pass
# 测试一个类的方法,没有外部依赖
def test_maths_add_0(self ,):
a,b=1,2
my_math = maths()
result = my_math.add(a,b)
self.assertEqual(result, 3)
# 测试一个类的方法,并假设 self.add 的返回值是10
def test_maths_add2_0(self ,):
a,b=1,2
my_math = maths()
maths.add = mock.Mock(return_value = 10) # 假设 self.add 的返回值是10
result = my_math.add2(a,b)
self.assertEqual(result, 10)
# 测试一个类的方法,并假设调用外部函数的返回值是 10
# 假设内部调用的类方法的返回值也是10
@mock.patch('unittest.pyauto_unittest_test.other_func')
def test_maths_mul_0(self , mock_other_func):
mock_other_func.return_value = 10 # 假设外部调用函数返回值是10
a,b=1,2
my_math = maths()
maths.add = mock.Mock(return_value = 10) # 假设内部调用的类方法也是10
result = my_math.mul(a,b)
self.assertEqual(result, 20)
# 测试一个函数,并假设内部调用的func_mul函数的返回值是10
@mock.patch('unittest.pyauto_unittest_test.func_mul')
def test_func_add_0(self , mock_func_mul):
mock_func_mul.return_value = 10 # 假设内部调用的函数返回值是10
a,b=1,2
result = func_add(a,b)
self.assertEqual(result, 20)
if __name__ == '__main__':
unittest.main()
看到没,这就是简单的单元测试的写法,已经涵盖了大部分测试用例写法。我们的目标,就是自动生成这样的测试用例。
既然都是模板套出来的,就很简单了。
5. 函数文档格式要求
既然是要自动生成代码,就需要事先约定格式要求,我们约定函数文档如下:
class maths():
def __init__(self):
pass
def add(self, a,b):
"""
# 测试用例代码需要夹在 两个 === unittest === 之间
=== unittest ===
a,b=1,2 # 一些初始化参数
mock.Mock maths.add=10 # mock 类的方法,可以是外部调用的类
mock.patch other_func=10 # mock 一个函数
my_math = maths() # 实例化当前类
input = my_math.add(a,b) # 输入,即要测试的方法
output = 3 # 输出,要进行assertEqual的值
=== unittest ===
other unittest # 如果有多个测试,接着往下添加即可
=== unittest ===
"""
return a+b
不管是测试函数还是测试类的方法啊,都以上面的格式约定规范化,是不是很简答啊。 我们就根据这些文档内容生成上面的测试用例,只要一一对应即可。
6. 生成测试用例
经过上面的讲解说明,接下来要做的事情就很简答了,包括遍历整个项目的每一个python文件,遍历每个模块的函数和类方法,提取函数文档,解析文档内容,依照格式生成对应的测试用例文件即可。
下面是配套资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!
最后: 可以在公众号:程序员小濠 ! 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!