网络核心后端单元测试的实现方法 - 行业资讯 - 肥雀云

　　介绍

这篇文章主要介绍了净核心后端单元测试的实现方法,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获、下面让小编带着大家一起了解一下。

1。前言

单元测试一直都是“好处大家都知道很多,但是因为种种原因没有实施起来“的一个老大难问题。具体是否应该落地单元测试,以及落地的程度,每个项目都有自己的情况。

本篇为个人认为“如何更好地写单元测试“,即更加<强>偏向实践向中夹杂一些理论的分享。

下列示例的单元测试框架为<代码> xUnit> Moq

2。为什么需要单元测试

优点有很多,这里提两点我个人认为的很明显的好处

2.1防止回归

通常在进行新功能/模块的开发或者是重构的时候,测试会进行回归测试原有的已存在的功能,以验证以前实现的功能是否仍能按预期运行。

使用单元测试,可在每次生成后,甚至在更改一行代码后重新运行整套测试,从而可以很大程度减少回归缺陷。

2.2减少代码耦合

当代码紧密耦合或者一个方法过长的时候,编写单元测试会变得很困难。当不去做单元测试的时候,可能代码的耦合不会给人感觉那么明显。为代码编写测试会自然地解耦代码,变相提高代码质量和可维护性。

3。基本原则和规范

, 3.1 3原则

3分别是“行动,assert"安排,分别代表一个合格的单元测试方法的三个阶段

<李>

事先的准备

<李>

测试方法的实际调用

<李>

针对返回值的断言

一个单元测试方法可读性是编写测试时最重要的方面之一。在测试中分离这些操作会明确地突出显示调用代码所需的依赖项,调用代码的方式以及尝试断言的内容。

所以在进行单元测试的编写的时候,请使用注释标记3出的各个阶段的,如下示例

[事实] 　　public async Task VisitDataCompressExport_ShouldReturnEmptyResult_WhenFileTokenDoesNotExist () 　　{//才能安排　　var 才能;mockFiletokenStore =, new Mock (); 　　mockFiletokenStore才能　　,,,每次(it =祝辞,it.Get (It.IsAny ())) 　　,,,.Returns (string.Empty); 　　　　var 才能;controller =, new StatController ( 　　,,,mockFiletokenStore.Object, 　　,,,空);//,才能行动　　var 才能;actual =, await controller.VisitDataCompressExport (“faketoken");//才能维护　　Assert.IsType<才能;EmptyResult>(实际); 　　}

3.2尽量避免直接测试私有方法

尽管私有方法可以通过反射进行直接测试,但是在大多数情况下,不需要直接测试私有私人的方法,而是通过测试公共公共方法来验证私有私人的方法。

可以这样认为:私人方法永远不会孤立存在。更应该关心的是调用私人方法的公共方法的最终结果。

3.3重构原则

如果一个类/方法,有很多的外部依赖,造成单元测试的编写困难。那么应该考虑当前的设计和依赖项是否合理。是否有部分可以存在解耦的可能性。选择性重构原有的方法,而不是硬着头皮写下去。

3.4避免多个断言

如果一个测试方法存在多个断言,可能会出现某一个或几个断言失败导致整个方法失败。这样不能从根本上知道是了解测试失败的原因。

所以一般有两种解决方案

<李>

拆分成多个测试方法

<李>

使用参数化测试,如下示例

(理论) 　　[InlineData (null)] 　　[InlineData (“a")) 　　public void Add_InputNullOrAlphabetic_ThrowsArgumentException (string 输入) 　　{//才能安排　　var 才能;stringCalculator =, new StringCalculator ();//,才能行动　　Action 才能;actual =,(),=祝辞,stringCalculator.Add(输入);//才能维护　　Assert.Throws<才能;ArgumentException>(实际); 　　}

当然如果是对对象进行断言,可能会对对象的多个属性都有断言。此为例外。

3.5文件和方法命名规范文件名规范

一般有两种。比如针对<代码>用户> UserControllerTest> UserController_Test>

单元测试方法名

单元测试的方法名应该具有可读性,让整个测试方法在不需要注释说明的情况下可以被读懂。格式应该类似遵守如下