前言

在做自动化过程中，通过数据驱动主要是为了将用例数据和用例逻辑进行分离，提高代码的重用率以及方便用例后期的维护管理。

很多小伙伴在使用 unittest 做自动化测试的时候，都是用的 ddt 这个模块来实现数据驱动的。也有部分小伙伴对 ddt 内部实现的源码比较感兴趣，前段时间小编在开发 unttestreport 的时候也写了一版数据驱动，使用的入口和 ddt 差不多，今天就给大家分析一下 unittestreport 中数据驱动(ddt)，源码实现的过程！

在给大家分析源码之前先给大家讲解一下 unittestreport 中的 ddt 如何使用！unittestreport.dataDriver 模块中实现了三个使用方法，支持使用列表(可迭代对象)、JSON 文件、YAML 文件来生成测试用例，这边给大家介绍一下使用方法：

1、模块导入

2、使用案例

第一步：使用 ddt 装饰测试用例类

第二步：根据使用的数据选择对应的方法进行驱动

第三步：运行上面用例文件，就会发现执行了三条测试用例

在上面的使用案例中我们使用了一个 ddt 的装饰器去装饰测试用例类，一个 list_data 的装饰器去装饰测试用例方法。

1、ddt

在上面的用例类前面我们用了一个@ddt 这行代码的作用到底是什么呢？

我们来看一下 ddt 里面的源码

从上面的源码我们可以看出来，把测试类当成参数传入 data 之后，在内部做了一系列操作之后将测试类返回了出来。这一系列操作其实就是根据测试用例数据，创建测试用例方法添加到测试类中，代码中重要步骤如下图描述所示。

对于上面遍历，判断方法是否拥有 PARAMS 属性，这个 PARAMA 属性是怎么来的呢？PARAMA 属性是@list_data(cases)的时候添加的，接下来我们来看一下 list_data 的源码

2、list_data

上面案例中@list_data(cases)这行代码的作用等同于 test_case = list_data(cases)(test_case)，我们来看一下源码。

通过源码我们可以发现执行@list_data(cases)的时候只做了一件事情，就是给测试用例方法添加了一个 PARAMS 属性。

通过上面的源码分析，我们来简单的讲一下，关于 ddt 实现的具体流程。

在 ddt 这个函数中我们调用了 _create_test_name 和 _update_func 这两个内部方法，那么这两个内部方法中分别做了什么事情呢？接下来分别来看一下

可以看到该方法会根据传进来的 index(用例数据的索引)和原用例名进行拼接，生成一个新的用例方法名。

从上面的代码可以看到，这个函数内部重写定义了一个函数，将原来的函数保存为了这个函数对象的属性，并设置了函数名，以及函数相关的文档字符串，最后将函数返回了。函数内部调研的还是原来的函数(测试用例方法)。

1、将所有的测试用例数据保存为测试方法的 PARAMS 属性。

2、遍历测试类的所有属性和方法。

3、判断遍历出来的属性或者方法是否拥有 PARAMS 属性。

4、如果拥有 PARAMS 属性，那么就遍历 PARAMS 中的测试数据。

5、每遍历出来一条数据，就创建一个测试方法，并将测试方法添加为测试类的类属性。

关于数据驱动实现的源码就给大家介绍到这里了，另附 unittestreport 模块详细的使用文档，里面有关于更多的 uniitestreport 扩展使用功能哦。有兴趣的小伙伴可以去看一下：unittestreport 详细功能使用文档（V1.1.1）

说明：本文为柠檬班木森老师原创，转载需注明出处！