[发明专利]一种单元测试方法、装置、电子设备及存储介质

说明书

本发明公开了一种单元测试方法、装置、电子设备及存储介质，用于解决现有的单元测试方法开销过大的技术问题。本发明包括：在预设业务中确定待测试单元和所述待测试单元的依赖单元；获取所述待测试单元的测试数据；创建所述依赖单元的mock对象，以模拟执行所述依赖单元；采用所述测试数据和所述mock对象测试所述待测试单元，得到测试结果。本发明通过创建待测试单元的依赖单元的mock对象，来模拟依赖单元的执行以获取待测试单元需要的返回数据，并结合测试数据对待测试单元进行测试，从而无需执行依赖单元的执行流程，减少了单元测试的执行过程，简化了测试程序，降低了单元测试的开销。

技术领域

本发明涉及应用测试技术领域，尤其涉及一种单元测试方法、装置、电子设备及存储介质。

背景技术

当一个应用程序需要进行功能调整时，往往需要重构内部的执行代码。重构代码需要大量的单元测试用例。单元测试，是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在现有的单元测试的一般方案，有如下缺点：

1、由于单元测试彼此之间的“独立”特性，会导致一个复杂的测试方法可能需要很多单元测试才能去覆盖一个完成的业务场景，例如，小程序内部架构实现的任何改动(例如版本升级、添加新功能)也都需要独立地设置一个单元测试，从而对开发带来较大的工作量；

2、在单元测试过程中需要很多依赖项，如数据库，因此需要去定义大量的原生jdbc接口来进行数据查询等，从而造成了开发人员的额外开销；

3、现有的单元测试中需要经常构造数据来完成单元测试，例如对支付模块的单元测试，需要预先频繁地构造待支付的订单数据作为测试数据，以该测试数据来测试支付模块是否正常，从而导致测试过程的开销过大。

发明内容

本发明提供了一种单元测试方法、装置、电子设备及存储介质，用于解决现有的单元测试方法开销过大的技术问题。

本发明提供了一种单元测试方法，包括：

在预设业务中确定待测试单元和所述待测试单元的依赖单元；

获取所述待测试单元的测试数据；

创建所述依赖单元的mock对象，以模拟执行所述依赖单元；

采用所述测试数据和所述mock对象测试所述待测试单元，得到测试结果。

可选地，所述获取所述待测试单元的测试数据的步骤，包括：

获取所述预设业务的业务数据；

获取所述待测试单元的配置文件；

根据所述业务数据和所述配置文件，生成所述待测试单元的测试数据。

可选地，所述根据所述业务数据和所述配置文件，生成所述待测试单元的测试数据的步骤，包括：

从所述配置文件中提取存储数据结构；

在所述存储数据结构中填充所述业务数据，并通过所填充的业务数据生成所述待测试单元的测试数据。

可选地，所述创建所述依赖单元的mock对象，以模拟执行所述依赖单元的步骤，包括：

确定所述依赖单元的API接口，并获取所述API接口的数据结构；

基于所述API接口的数据结构，生成所述依赖单元的mock对象，以模拟执行所述依赖单元。