**TDSL** (Test Domain Specific Language), 测试领域专用语言，是一套高效简洁描述测试代码的规范脚本语法。

- **1.1、为什么要使用TDSL**

  单元测试是前端开发中重要的一部分工作，但常常由于时间紧张，除了要写测试用例代码，还要维护旧的用例，每个人用例写法多少也有不一致，同伴的用例代码也往往会含有特殊的想法和逻辑，而且代码量大修改起来也难定位，前前后后也消耗了不少时间。不得不说，用例虽不难，但持续性开发维护会让我们投入不少精力。

  由于测试用例大部分都是单元模块IO的验证代码，核心代码比较固定和机械化，但是往往修改了代码，还要去改用例，非常闹心。实际上我们可以根据源码进行ast分析，解析出各个模块的输入输出结构，直接生成用例代码，我们只需要指令式管理IO样本数据即可。所以，这里定义了一套简洁的描述语法规则TDSL。TDSL的基础理念是：重复类似的测试用例的代码只需要工具写一次，其他的交给TDSL。

  而为了做到跨技术栈使用，可通过tdsl.config.js配置来适配自己的项目。开发者只需要在注释中写指令语法就可以了。

- **1.2、TDSL引入的优势**

  所有语法必须写在函数前的块注释(/**/)中。然后自动生成对应的完整jest测试用例代码。

  **优势**：

1，不用手写用例代码，也不用维护用例代码。

2，从注释直观开发ut测试IO，面向指令，所有用例和模块IO一目了然。边界IO也更加直观。

3，统一用例代码，使用核心常用语法，保持一致性 (其实完全不用关心)。

4，约束源码实现，约束一个函数只做一件IO事情，手动编写的用例过于灵活，后面其他人维护成本较高。

5，大大降低TDD成本。

6，注释文档、逻辑、用例同步更新，避免同步的成本。

7，统一IO数据样本文件管理，样本数据更易维护。

8，提高效率的同时对源码的组织结构形成反向约束。 (例如针对函数模块使用块注释，才能自动生成用例)

9，覆盖率低？不存在的。

  **劣势**: 

1，增加注释量。(但其实更加完善了，对于陌生的模块，更容易理解IO并上手)

2，TDSL语法成本。(但是不用再去折腾测试用例api怎么写了，TDSL语法远比用例语法简单)