一种单元测试方法及系统与流程

专利2022-06-29  89


本发明涉及软件技术领域,特别涉及一种单元测试方法及系统。



背景技术:

在分布式场景中,涉及到很多服务之间互相依赖的场景。对某一个服务进行单元测试时,如果依赖服务存在不可用等问题,就会导致针对该服务的单元测试失败。可以看出大量的服务互相依赖,会导致单元测试失败不可控。

所以,亟待解决单元测试避免失败不可控成为本领域技术人员亟待解决的问题。



技术实现要素:

基于上述技术问题,本发明的发明目的在于提供一种单元测试方法及系统。

本申请实施例第一方面示出一种单元测试方法,包括:

获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

本申请实施例第二方面示出一种测试系统,包括:

mock配置文件,所述mock配置文件包括mock总开关状态;

依赖服务;

json配置文件,所述json配置文件包括依赖服务的mock开关状态;

服务器,被配置为:获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

本申请实施例第三方面示出一种服务器,被配置为:

获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

由以上技术方案可以看出,本申请实施例示出一种单元测试方法及系统,本申请实施例示出的技术方案中,所述方法包括:获取mock总开关状态;响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;根据依赖服务的mock开关状态,确定依赖服务的输出结果;根据每个依赖服务的输出结果,确定单元测试结果。本申请实施例中,通过配置的mock总开关状态和每个依赖服务的mock开关状态,确定依赖服务的输出结果,可以使测试单元在依赖服务存在不可用或其他问题时正常进行。将影响单元测试正常进行的依赖服务通过利用本地数据替代直接调用依赖服务得到的输出结果,避免大量的服务互相依赖,导致单元测试失败不可控。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1中示例性示出了根据实施例中的一种单元测试方法的流程图;

图2中示例性示出了根据实施例中的单元测试系统的部分结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。以下结合附图,详细说明本申请各实施例提供的技术方案。

单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试过程中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。但是对软件的独立单元进行单元测试时,可能会利用依赖服务来完成单元测试,但是依赖服务如果存在不可用等问题,就会影响单元测试的正常进行。例如对服务c进行单元测试,服务c的单元测试结果需要通过依赖服务a的输出结果确定,而依赖服务a的输出结果需要通过依赖服务b的输出结果确定,此时如果依赖服务a和依赖服务b其中一个不能提供输出结果或者输出结果不满足要求,则单元测试无法进行。

常规的mock方法是在单元测试过程中,对于某些不容易构造或者不容易获取的服务,用一个虚拟的对象来创建以便测试的测试方法。但是常规的mock方法需要大量的人工编码,代码重复冗余。

基于上述技术问题,本申请第一方面示出一种基于常规的mock方法的单元测试方法。

所述方法应用在一种单元测试系统中,所述单元测试系统包括mock配置文件、依赖服务、json配置文件和服务器,所述mock配置文件包括mock总开关状态,所述json配置文件包括依赖服务的mock开关状态。

需要说明的是,本申请实施例通过配置的形式控制单元测试是否使用mock方法,也就是在mock配置文件中配置mock总开关状态,所述mock总开关状态可以为打开或者关闭。另外,为了避免依赖服务存在不可用等问题,本申请实施例设置有json配置文件,json配置文件中设置有依赖服务的mock开关状态,所述依赖服务的mock开关状态可以为打开或者关闭。

本申请实施例中,如图1所示,所述单元测试方法具体包括:

s100、获取mock总开关状态;需要说明的是,mock总开关控制整个单元测试是否使用mock方法,当单元测试过程中存在依赖服务不可用或者其他导致不能完成单元测试的情况,将mock总开关状态设置为打开,此时可以不再直接全部调用依赖服务,而是可以根据依赖服务的具体情况,将部分依赖服务利用本地数据替代调用依赖服务得到的输出结果,可以避免单元测试失败不可控的问题。当单元测试过程中不存在依赖服务不可用或者其他导致不能完成单元测试的情况,将mock总开关状态设置为关闭,此时,单元测试的过程为直接调用所有依赖服务。所述本地数据是指预置的依赖服务的输出结果。

响应于mock总开关状态为关闭,则调用全部依赖服务,得到依赖服务的输出结果。

s200、响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

具体的,当mock总开关状态为打开时,确定每个依赖服务的mock开关状态。在本申请实施例中,所述获取每个依赖服务的mock开关状态的过程为在单元测试中需要利用某个依赖服务的输出结果时,获取对应的依赖服务的mock开关状态,确定依赖服务的输出结果。随后继续进行单元测试,按单元测试中利用依赖服务的顺序,当需要利用单元测试中的另一个依赖服务的输出结果时,获取该依赖服务的mock开关状态,随后确定该依赖服务的输出结果。

本申请实施例中,由于单元测试中可能存在多个依赖服务,其中有部分依赖服务可能不可用,不能通过直接调用的方式,得到这部分依赖服务的输出结果,此时可以配置该部分依赖服务的mock开关状态为打开。例如,当单元测试过程中需要依赖服务a,依赖服务b和依赖服务c的输出结果时,如果依赖服务b和依赖服务c不可用或存在其他导致不能完成单元测试的情况,则可以配置依赖服务b和依赖服务c的mock开关状态为打开,依赖服务a的mock开关状态为关闭。

在一些实施例中,所述响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态的步骤包括:

所述json配置文件还包括依赖服务地址,所述依赖服务的mock开关状态与所述依赖服务地址对应;

响应于mock总开关状态为打开,确定依赖服务对应的依赖服务地址,当mock总开关状态为打开,在需要利用依赖服务的输出结果时,确定该依赖服务的依赖服务地址。

根据依赖服务地址,在json配置文件中查找到与该依赖服务地址对应的依赖服务的mock开关状态。

s300、根据依赖服务的mock开关状态,确定依赖服务的输出结果;

具体的,依赖服务的mock开关状态不同,则依赖服务的输出结果的来源不同。在一些实施例中,所述根据依赖服务的mock开关状态,确定依赖服务的输出结果的步骤包括:

响应于依赖服务的mock开关状态为打开,获取依赖服务对应的本地数据,作为依赖服务的输出结果,所述本地数据为预置的依赖服务的输出结果;

响应于依赖服务的mock开关状态为关闭,则调用依赖服务,将调用依赖服务得到的输出结果作为依赖服务的输出结果。

具体的,当单元测试过程中的依赖服务不可用或者其他导致不能完成单元测试,则可以设置依赖服务的mock开关状态为打开,此时,不再直接调用依赖服务,而是利用预置的依赖服务对应的本地数据替代直接调用依赖服务得到的输出结果,这样依赖服务不可用或其他导致不能完成单元测试的问题就不会影响单元测试的正常进行。另外,当单元测试过程中的依赖服务的输出结果不会影响单元测试的正常进行,则设置该依赖服务的mock开关状态为关闭,此时直接调用依赖服务。

s400、根据每个依赖服务的输出结果,确定单元测试结果。

如图2所示,图2是本申请实施例中单元测试系统的部分结构示意图,在进行单元测试时,利用到依赖服务a,依赖服务b,依赖服务c。依赖服务a和依赖服务c可提供输出结果,但是依赖服务b由于开发进度未完成或者输出结果的数据问题不能有效提供。此时可以设置依赖服务a的mock开关状态为关闭,依赖服务b的开关状态为打开,依赖服务c的开关状态为关闭。当开始进行单元测试时,如果首先使用依赖服务a的输出结果,此时获取依赖服务a的mock开关状态,当依赖服务a的mock开关状态为关闭,则直接调用依赖服务a得到的结果为依赖服务a的输出结果。继续进行单元测试,此时如果需要使用依赖服务b的输出结果,则获取依赖服务b的mock开关状态,如果依赖服务b的mock开关状态为打开,则利用预置的本地数据作为依赖服务b的输出结果,随后继续单元测试,此时需要使用依赖服务c的输出结果,此时获取依赖服务c的mock开关状态,如果依赖服务c的mock开关状态为关闭,则直接调用依赖服务c得到的结果为依赖服务c的输出结果。

需要说明的是,本申请实施例中可以将多个依赖服务组合在一起,只需要通过配置json配置文件确定每个依赖服务的mock开关状态即可实现不同独立单元的单元测试,无需和通常的mock方法一样,对于不同的独立单元的单元测试均需要通过重写编写大量的编码实现,这样节约了对独立单元的单元测试需要花费的时间。

本申请实施例中的单元测试不仅仅是作为无错编码的一种辅助手段应用于一次性的开发过程,另外,无论是在软件修改过程中,还是移植到新的运行环境之后,单元测试也是必不可少的。在自动化构建软件的过程中,通过单元测试是最基础的发版标准,所以如果依赖服务不可用,将导致单元测试的失败,严重影响了开发过程的发版效率,使自动化构建软件的过程受阻。本申请实施例中,通过配置的mock总开关状态和每个依赖服务的mock开关状态,确定依赖服务的输出结果,可以使测试单元在依赖服务存在不可用或其他问题时正常进行,将影响单元测试正常进行的依赖服务通过利用本地数据替代直接调用依赖服务得到的输出结果,避免大量的服务互相依赖,导致单元测试失败不可控。

本申请示出第二方面示出一种测试系统,包括:

mock配置文件,所述mock配置文件包括mock总开关状态;

依赖服务;

json配置文件,所述json配置文件包括依赖服务的mock开关状态;

服务器,被配置为:获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

本申请示出第三方面示出一种服务器,被配置为:

获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

本申请示出第四方面示出一种可读存储介质,所述可读存储介质中存储有单元测试程序,所述单元测试程序被处理器执行时实现单元测试的步骤。

由以上技术方案可以看出,本申请实施例示出一种单元测试方法及系统,本申请实施例示出的技术方案中,所述方法包括:获取mock总开关状态;响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;根据依赖服务的mock开关状态,确定依赖服务的输出结果;根据每个依赖服务的输出结果,确定单元测试结果。本申请实施例中,通过配置的mock总开关状态和每个依赖服务的mock开关状态,确定依赖服务的输出结果,可以使测试单元在依赖服务存在不可用或其他问题时正常进行。将影响单元测试正常进行的依赖服务通过利用本地数据替代直接调用依赖服务得到的输出结果,避免大量的服务互相依赖,导致单元测试失败不可控。

基于本申请中示出的示例性实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。此外,虽然本申请中公开内容按照示范性一个或几个实例来介绍,但应理解,可以就这些公开内容的各个方面也可以单独构成一个完整技术方案。

此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖但不排他的包含,例如,包含了一系列组件的产品或设备不必限于清楚地列出的那些组件,而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。


技术特征:

1.一种单元测试方法,其特征在于,包括:

获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

2.根据权利要求1所述的方法,其特征在于,所述根据依赖服务的mock开关状态,确定依赖服务的输出结果的步骤包括:

响应于依赖服务的mock开关状态为打开,获取依赖服务对应的本地数据,作为依赖服务的输出结果,所述本地数据为预置的依赖服务的输出结果;

响应于依赖服务的mock开关状态为关闭,则调用依赖服务,将调用依赖服务得到的输出结果作为依赖服务的输出结果。

3.根据权利要求1所述的方法,其特征在于,还包括:

响应于mock总开关状态为关闭,则调用全部依赖服务,得到依赖服务的输出结果。

4.根据权利要求1所述的方法,其特征在于,所述响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态的步骤包括:

响应于mock总开关状态为打开,确定依赖服务地址;

根据依赖服务地址,查找到依赖服务的mock开关状态。

5.根据权利要求1所述的方法,其特征在于,所述mock总开关状态设置在mock配置文件中。

6.根据权利要求1所述的方法,其特征在于,所述依赖服务的mock开关状态设置在json配置文件中。

7.一种测试系统,其特征在于,包括:

mock配置文件,所述mock配置文件包括mock总开关状态;

依赖服务;

json配置文件,所述json配置文件包括依赖服务的mock开关状态;

服务器,被配置为:获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

8.一种服务器,其特征在于,被配置为:

获取mock总开关状态;

响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;

根据依赖服务的mock开关状态,确定依赖服务的输出结果;

根据每个依赖服务的输出结果,确定单元测试结果。

技术总结
本申请实施例示出一种单元测试方法及系统,本申请实施例示出的技术方案中,所述方法包括:获取mock总开关状态;响应于mock总开关状态为打开,则获取每个依赖服务的mock开关状态;根据依赖服务的mock开关状态,确定依赖服务的输出结果;根据每个依赖服务的输出结果,确定单元测试结果。本申请实施例中,通过配置的mock总开关状态和每个依赖服务的mock开关状态,确定依赖服务的输出结果,可以使测试单元在依赖服务存在不可用或其他问题时正常进行。将影响单元测试正常进行的依赖服务通过利用本地数据替代直接调用依赖服务得到的输出结果,避免大量的服务互相依赖,导致单元测试失败不可控。

技术研发人员:郭伟;王绍民
受保护的技术使用者:聚好看科技股份有限公司
技术研发日:2020.01.08
技术公布日:2020.06.09

转载请注明原文地址: https://bbs.8miu.com/read-26617.html

最新回复(0)