TypeScript 如何写单元测试

如果你平时写 JS 项目，可能会依赖单元测试来排查小问题；那换成 TypeScript 后，该怎么把这个测试流程衔接上？其实根本不用把 TypeScript 想得太特殊，它的“类型安全”特性反而能帮你少踩测试的坑——咱们从最基础的步骤说，连没写过单元测试的人也能跟着做。

第一步：先搭好基础工具

想测 TS 代码，得先装几个顺手的工具，都是前端圈常用的，不会太复杂。首先是测试框架，选 Jest 就行，它支持 TS 直接跑，不用自己折腾转码；然后要加 Jest 的 TS 适配包，还有用来解析 TS 的编译器。

举个生活化的例子：这就像你要给家里的绿植浇水，框架是“浇水壶”，适配包是“适配浇花的喷头”，编译器是“把自来水调成适合绿植的温水”——缺了任何一样，要么浇不透，要么会伤花。装完后在项目根目录建个简单的测试配置文件，写几行基础规则，比如告诉工具“用 TS 解析测试文件”，就算搭好了基础环境。

第二步：写一个最简单的 TS 测试

先从一个普通人都懂的功能入手，比如写一个“计算快递运费”的函数：根据包裹重量，每公斤收 8 元，不满 1 公斤按 1 公斤算。用 TS 写的话，得给函数加类型，比如参数是 number，返回值也是 number。

对应的测试文件要和原函数放一起，名字改成“原函数名.test.ts”，比如叫 freight.test.ts。里面写测试的逻辑很直白：比如“包裹重 2.3 公斤，运费该是 24 元”，“包裹重 0.5 公斤，运费该是 8 元”。

这里要提个 TS 的小优势：如果原函数写错了，比如把重量参数写成字符串，测试会直接报错——不像 JS 里你可能要跑很久才发现，类型检查提前就把错误拦下来了，就像快递员送件前先核对地址，错了根本出不了门。

第三步：处理 TS 里的特殊场景

TS 有类型，测试时会遇到一些 JS 不会有的情况，比如可选参数、联合类型。比如刚才的运费函数，加个可选的“偏远地区附加费”参数，默认 5 元。这时候测试不仅要测普通情况，还要测“没传附加费”和“传了不同附加费”的情况。

举个例子：你去买奶茶，默认加珍珠，有时候可以选加芋圆，测试就要既测“默认加珍珠的奶茶”，也测“选加芋圆的奶茶”，不能只测一种。这时候写测试时，要把这些分支都覆盖到，别漏了可选参数的场景，不然 TS 帮你做的类型校验就白用了。

第四步：跑测试和调错

写完测试后，在 package.json 里加个运行命令，比如 test，然后直接在终端输命令就行。如果测试报错，先看是原函数的问题还是测试的问题——如果是类型错误，大概率是你给参数传了不符合类型的值，比如给重量传了字符串“5公斤”，这时候改函数或者测试的参数就行。

举个生活化的例子：这就像你煮面，测试是“尝面”，如果尝着咸了，要么是盐放多了（原函数逻辑错），要么是你加的盐不对（测试参数错），找到对应地方调整就好。

最后说一句：给 TypeScript 写单元测试，核心就是把 TS 的类型优势和测试的逻辑验证结合，不用搞复杂的东西，先从简单的函数测起，慢慢覆盖更多场景，就能把代码的稳定性提上去。