一文搞懂Unittest测试方法执行顺序

简介: 一文搞懂Unittest测试方法执行顺序

大家好~我是米洛

Unittest


unittest大家应该都不陌生。它作为一款博主在5-6年前最常用的单元测试框架,现在正被pytest,nose慢慢蚕食

渐渐地,看到大家更多的讨论的内容从unittest+HTMLTestRunner变为pytest+allure2等后起之秀

不禁感慨,终究是自己落伍了,跟不上时代的大潮了。

回到主题


感慨完了,回到正文。虽然unittest正在慢慢被放弃,但是它仍然是一款很全面的测试框架

今天在群里看到番茄卷王(公众号: 测试开发番货)的一番言论,激起了我的一番回忆。

自己以前是知道unittest的执行顺序并不是按照编写test方法的顺序执行,而是按照字典序执行的。但遗憾的是我都是投机取巧去解决的问题(后面会讲)。

下面我们就来探讨下unittest类的test方法的执行顺序问题。

源码初窥


研究一下源码(unittest.TestLoader)可以发现,在加载一个class下面的test方法的时候,原生Loader进行了排序,并且根据functools.cmp_to_key方法对测试方法列表进行了排序。

1.jpg

image

我们知道,unittest是不需要我们指定对应的方法,说白了,它是从类里面自动获取到咱们的方法,并约定了以test开头的方法都会被视为测试方法。

2.jpg

可以看到testMethodPrefix,即测试方法前缀,如果不是test开头则直接return False

查询一下self.sortTestMethodsUsing(这个是一个排序的方式)。

3.jpg

找到对应的排序方法

可以看到这个比较方法写的很明确了,如果x < y那么返回-1,x = y则返回0,x > y返回1。

其实大家可能不知道Python里面的字符串也是可以比较的,在此必须说明一下字典序。我们来看看这个例子:


a = "abc"
b = "abcd"
c = "abce"
print(a > b)
print(b > c)

猜猜看执行结果,很显然,字典序的比较,是按A-Z的顺序来比较的,如果前缀一样但长度不一样,那么长度长的那个,字典序靠后。

4.jpg

所以这里面a < b < c

了解了字典序以后,我们就不难知道,在unittest里面它寻找case的过程可以这样简化:

  • 找到对应类下面以test开头的测试方法
  • 对他们进行字典序排序
  • 依次执行
    这样就不难解释为什么我们有时候写的case不按照自己想的顺序来

回到问题的本质


搞清楚为什么用例会乱,那就想到对应的解决方案。由于修改源码是不太合适的,那我们有2个策略去达成目的。

比如我有多个test方法:


class Testcase(unittest.TestCase):
    def setUp(self) -> None:
        pass
    def test_1(self):
        print("执行第一个")
    def test_2(self):
        print("第二个")
    def test_3(self):
        print("第三个")
    def test_10(self):
        print("第四个")
    def test_11(self):
        print("第五个")
    def tearDown(self) -> None:
        pass
if __name__ == "__main__":
    unittest.main()

执行起来,按照字典序,其实是1 10 11 2 3的顺序。

5.jpg

可以看到现在还是不对的

1. 以字典序的方式编写test方法


我们可以手动修改test方法的名称,这也是我早前的处理方式。也就是说把想要先执行的case字典序排到前面:


class Testcase(unittest.TestCase):
    def setUp(self) -> None:
        pass
    def test_0_1(self):
        print("执行第一个")
    def test_0_2(self):
        print("第二个")
    def test_0_3(self):
        print("第三个")
    def test_1_0(self):
        print("第四个")
    def test_1_1(self):
        print("第五个")
    def tearDown(self) -> None:
        pass

我们可以把数字按位数拆开,个位数就把10位补0,这样就能达到效果,如果会写100个case,我们就需要补2个0,比如0_0_1,当然一个文件里面也不会有太多case。

如果遇到test_login这种怎么办呢,不是数字结尾的方法。

其实是一样的,可以写成test_数字_业务的模式。番货写了一个装饰器专门解决这样的问题,大家可以去参考下。

2. 回归本质,从根本解决问题


方案1用了番货的装饰器,好是好,但是改变了方法本身的名称,我们其实可以针对他的排序方式入手,按照我们编写case的顺序排序测试方法,就能达到想要的目的。

说说思路:

  1. 手写一个loader继承自TestLoader类,改写里面的排序方法
  2. 在unittest运行的时候传入这个新的loader

来看看完整代码,注释里面写的很完善了。


import unittest
class MyTestLoader(unittest.TestLoader):
    def getTestCaseNames(self, testcase_class):
        # 调用父类的获取“测试方法”函数
        test_names = super().getTestCaseNames(testcase_class)
        # 拿到测试方法list
        testcase_methods = list(testcase_class.__dict__.keys())
        # 根据list的索引对testcase_methods进行排序
        test_names.sort(key=testcase_methods.index)
        # 返回测试方法名称
        return test_names
class Testcase(unittest.TestCase):
    def setUp(self) -> None:
        pass
    def test_1(self):
        print("执行第一个")
    def test_2(self):
        print("第二个")
    def test_3(self):
        print("第三个")
    def test_10(self):
        print("第四个")
    def test_11(self):
        print("第五个")
    def tearDown(self) -> None:
        pass
if __name__ == "__main__":
    unittest.main(testLoader=MyTestLoader())

6.jpg

执行一下还是不对

执行了一下还是不对,是不是哪里出了什么问题呢?

是因为pycharm有一种默认的unittest的调试方法,我们要改成普通的方法去执行。

7.jpg

这种就是unittest的专属测试模式

8.jpg

改成data(我的py文件名称),然后点击debug按钮

9.jpg

别选Python tests,选正常的Python

10.jpg

搞定

试试用控制台执行:

11.jpg

也没什么毛病


今天的内容就讲到这里了,看懂的记得给个赞哦~




相关文章
|
13天前
|
敏捷开发 测试技术 持续交付
软件测试中的探索性测试方法及其重要性
【8月更文挑战第6天】在软件开发周期中,测试环节是不可或缺的。它确保了产品的质量、性能与可靠性。然而,传统的测试方法往往侧重于预设的测试用例和场景,可能忽略了用户实际使用过程中的非预期行为。探索性测试(ET)应运而生,它强调测试人员的自主性和创造性,通过不断学习和适应来发现软件的潜在缺陷。本文将探讨探索性测试的概念、实施策略及其在现代软件开发中的重要性。
|
11天前
|
SQL 安全 测试技术
[go 面试] 接口测试的方法与技巧
[go 面试] 接口测试的方法与技巧
|
14天前
|
测试技术 持续交付
探索式测试:一种灵活的软件质量保证方法
在软件测试领域,探索式测试是一种与传统脚本测试截然不同的方法。它强调测试人员的自主性与创造性,允许他们在执行测试时即时设计和执行测试用例。这种方法的灵活性和适应性使其成为发现复杂软件系统中难以预测的错误的有效手段。本文将深入探讨探索式测试的核心概念、实施策略以及它在现代软件开发生命周期中的价值。
29 4
|
14天前
|
敏捷开发 测试技术
探索式测试:一种高效灵活的质量保证方法
在软件生命周期中,确保产品质量是至关重要的一环。传统的测试方法往往依赖于预设的测试用例,而忽视了测试过程中的灵活性和创造性。本文将介绍一种与传统测试截然不同的方法—探索式测试,它强调个人技能与经验的应用,鼓励测试人员发挥主观能动性,通过不断探索来发现更多潜在的软件缺陷。文章将详细阐述探索式测试的核心概念、实施步骤及其在现代软件开发中的实际应用案例,旨在为读者提供一种更为高效和灵活的测试策略。
|
19天前
|
测试技术
软件测试中的探索性测试方法
在软件开发周期中,测试环节扮演着至关重要的角色。本文将深入探讨一种灵活而高效的测试方法——探索性测试。我们将通过具体实例分析其实施过程,并讨论如何通过这种方法提高软件质量和测试效率。最后,我们提出一个开放性问题,邀请读者思考探索性测试在他们工作中的实际应用和潜在价值。 【7月更文挑战第31天】
|
20天前
|
敏捷开发 测试技术
软件测试中的探索性测试:一种灵活的质量保证方法
在软件开发周期中,测试是确保产品质量的关键步骤。传统的测试方法往往依赖于事先定义好的测试用例,但这种方法可能无法覆盖所有潜在的缺陷和场景。探索性测试(ET)作为一种更为灵活的测试方式,允许测试人员在执行测试的同时设计和适应测试用例,从而提高了测试覆盖率并发现更多隐藏的缺陷。本文将探讨探索性测试的核心概念、实施策略以及与传统测试方法的比较,旨在为软件测试专业人员提供一种更高效、适应性强的测试手段。
|
25天前
|
敏捷开发 测试技术 持续交付
探索式测试:一种高效软件质量保证方法
在软件开发的复杂性不断增加的背景下,传统的测试方法已不能完全满足快速迭代和高质量标准的要求。探索式测试(Exploratory Testing)作为一种灵活且高效的软件测试实践,正逐渐成为质量保证过程中不可或缺的一部分。本文将深入探讨探索式测试的核心理念、实施策略以及与传统测试方法相比的优势,旨在为读者提供一套完整的探索式测试框架及其在实际项目中的应用示例。
|
26天前
|
测试技术
详解单元测试问题之MockHandlerImpl类的handle方法中VerificationMode不为空如何解决
详解单元测试问题之MockHandlerImpl类的handle方法中VerificationMode不为空如何解决
26 3
|
4天前
|
测试技术
单元测试问题之在单元测试中,方法的返回值或异常,如何验证
单元测试问题之在单元测试中,方法的返回值或异常,如何验证
|
4天前
|
测试技术
单元测试问题之模拟一个无返回值的方法,如何操作
单元测试问题之模拟一个无返回值的方法,如何操作

热门文章

最新文章