单元测试的规范

好的单元测试的标准

单元测试应该准确，快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：

1.4.2.1 单元测试应该在最低的功能/参数上验证程序的正确性

单元测试应该测试程序中最基本的单元 – 如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成），从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法，及其每一个参数。

1.4.2.2 单元测试必须由最熟悉代码的人（程序的作者）来写

代码的作者最了解代码的目的，特点，和实现的局限性。所以，没有比作者适合的人选。

问：如果我很忙，能不能让别人代劳单元测试？

答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试，但是，程序的作者还是要对单元测试负责。

最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。

1.4.2.3 单元测试过后，机器状态保持不变

这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段把这些临时的文件或目录删除。

如果单元测试在数据库中创建或修改了记录，那么也许要删除这些记录，或者每一个单元测试使用一个新的数据库，这样保证单元测试不受以前单元测试实例的干扰。

1.4.2.4 单元测试要快 (一个测试运行时间是几秒钟, 而不是几分钟)

快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次，网络通信层次，客户逻辑层次，和用户界面层次，可以分类运行测试，比如我只修改了“用户界面”的代码，我只需运行“用户界面”的单元测试。

单元测试的规范⼀、测试准则

必须满⾜AIR原则

A：Automatic（⾃动化）

I：Independent（独⽴性）

R：Repeatable（可重复）

可参照27条准则。

引⽤链接：

原⽂链接：如下：

27条准则⼆、结构规范

⽬录结构规范：

1.源码存放在src⽬录，每个功能模块创建单个npm包

2.src同级创建test/unit作为单元测试⽂件⽬录

3.test/unit⽬录下创建源npm包同名⽂件夹，⽤于存放单元测试⽂件

4.src同级创建test/integration作为集成测试⽂件夹

5.test/integration⽬录下创建源npm包同名⽂件夹，⽤于存放集成测试⽂件

⽂件命名规范：

1.test⽬录下测试⽂件名同源码⽂件名同名，后缀以.test.js结尾

2.test/unit和test/integration创建测试⽂件夹时，参照短横线（kabab-case）规范命名。

3.js和ts⽂件依照短横线（kabab-case）规范命名，Vue⽂件依照驼峰（camelCased）规范命名。

4.每个源码⽂件（如js，ts，vue）对应⼀个同名.test.js⽂件。（index⽂件可以忽略）三、编码原则

必须符合 BCDE 原则：

B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。

C：Correct，正确的输⼊，并得到预期的结果。

D：Design，与设计⽂档相结合，来编写单元测试。

E：Error，强制错误信息输⼊（如：⾮法数据、异常流程、⾮业务允许输⼊等），并得到预期的结果。

避免以下情况：

1）构造⽅法中做的事情过多。

2）存在过多的全局变量和静态⽅法。

3）存在过多的外部依赖。

4）存在过多的条件语句。

建议：

1.涉及到的某些扩展模块可以使⽤mock模拟

2.测试⽤例不要使⽤@ignored或者被注释掉，切记切记。如何编写更好的单元测试

原⽂链接：

单元测试在最近的⼯作中使⽤⽐较⼴泛，我已经收集了⼀些关于如何编写更好的测试类的准则，并且我已经尝试着坚持这些准则多年了。记住，编写糟糕的测试是在浪费时间，并会在以后造成更⼤的问题。所以最好把这些准则记在⼼⾥。

单元测试的规范

单元测试是软件开发过程中一个非常重要的环节，它用于验证程序的各个单元是否按照设计要求正常运行。为了确保单元测试的有效性和可靠性，开发人员需要遵循一些规范。本文将介绍单元测试的规范，并提供一些实用的建议。

1.选择合适的单元：

在进行单元测试之前，首先需要明确测试的目标单元。一个单元应该是最小可测试的功能模块，通常是一个函数、方法或者一个类。确保每个单元都能够独立于其他部分进行测试，这样可以更容易地定位和修复问题。

2.编写清晰的测试用例：

每个单元测试都应该有明确的测试目标和预期结果。测试用例应该覆盖各种情况，包括正常输入、边界条件和异常情况。编写清晰的注释和描述，以便其他开发人员可以轻松理解测试的意图和预期结果。

3.保持测试独立和可重复：

单元测试应该是独立的，不依赖于其他测试或外部环境。确保每个测试用例可以独立运行，并输出可重复的结果。这样可以帮助开发人员追踪问题和调试代码。如果测试依赖于外部资源或环境，可以使用模拟工具或框架来模拟这些依赖项。

4.测试覆盖率： 测试覆盖率表示在单元测试中覆盖了多少代码。在编写测试用例时，应该努力达到较高的测试覆盖率，尽可能覆盖程序的各个部分。通过使用代码覆盖率工具，可以检查哪些部分的代码没有被测试到，进而补充相应的测试用例。

5.单元测试的独立环境和频率：

为了确保单元测试的准确性和可靠性，应该为单元测试提供一个独立的测试环境。这个环境应该与实际生产环境相似，但又能够独立进行测试。此外，频繁地运行单元测试可以及早发现问题，并在开发过程中进行修复。

6.错误处理和断言：

在编写测试用例时，应该考虑到各种可能的错误情况，并编写相应的错误处理和断言。检查程序是否按照预期处理错误，并产生正确的结果。错误处理和断言帮助开发人员追踪问题和定位错误的源头。

7.持续集成和测试：

单元测试应该与持续集成过程结合，以确保在每次代码提交后都进行自动化的单元测试。持续集成工具可以自动运行测试，并及时通知开发人员有关测试结果的信息。这样可以确保问题能够及早发现，减少故障的传递。

单元测试的依据

单元测试是对软件基本组成单元进行测试。依据是：软件详细说明书。

为什么不是代码：单元测试测试的不仅仅是代码，有、接口测试、局部数据结构测试、独立路径测试、独立路径测试、边界条件测试、错误处理测试、功能测试、性能测试、内存使用测试等。

单元测试（unittesting），是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试[1]是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++这样的面向对象的语言中，要进行测试[2]的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，在这里基本单元被典型地划

分为一个菜单或显示界面。 经常与单元测试联系起来的另外一些开发活动包括代码走读（Codereview)，静态分析（Staticanalysis)和动态分析（Dynamicanalysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。