测试JavaScript或TypeScript代码 是否必须使用ts-jest？

ts-jest的核心作用 #

• 省略手动编译前置流程：ts-jest是Jest官方维护的TypeScript预处理器，会在测试执行时自动将TS源码（包括测试用例文件）实时编译为可执行的JS代码，不需要你提前手动执行tsc做全量编译，也不需要额外处理编译后产物的路径对应问题。
• 支持直接调试TS源码：如果你测试编译后的JS代码，调试时需要额外配置sourcemap才能对应到原始TS代码，ts-jest已经内置了sourcemap适配，测试报错的堆栈、断点调试都可以直接定位到TS源码的对应行，不需要和编译后的JS代码做映射匹配。
• 自动对齐TS工程配置：天然适配tsconfig中配置的路径别名（比如@/*）、装饰器等特殊语法，不需要你单独在Jest配置中重复做路径映射、语法转换的配置。同时可以选择在测试执行前先做TS类型检查，类型错误会直接在测试阶段抛出，不需要你单独跑类型校验命令。
• 支持TS编写测试用例：测试代码本身可以直接用TS编写，写用例阶段就能获得类型提示，避免测试代码本身的类型错误，不需要把测试用例也单独编译成JS再执行。

可以不使用ts-jest吗 #

答案是可以，但会大幅提升测试流程的维护成本。
如果不用ts-jest，你需要额外做以下配置：

• 每次跑测试前先执行tsc把业务代码和测试代码全量编译为JS，同时要确保tsconfig配置输出的sourcemap可用，才能把报错定位到原始TS代码。
• 手动配置Jest的路径映射，对齐TS编译后的JS文件路径，比如你TS里配置的@/utils别名，编译后可能变成了相对路径../utils，需要在Jest配置里单独对齐，否则会出现模块找不到的报错。
• 测试代码的类型校验需要单独执行tsc --noEmit完成，不会和测试执行流程绑定，容易出现测试代码有类型错误但仍然能跑通测试的情况。
• 如果你使用了TS的实验性语法比如装饰器，还要单独配置Babel做语法转换，否则编译后的JS代码可能无法正常执行。

如果你的项目规模极小，或者已经有成熟的全量编译配套流程，可以选择不使用ts-jest。但绝大多数TypeScript项目使用ts-jest可以大幅降低测试流程的配置和维护成本，是更推荐的方案。

内容的提问来源于stack exchange，提问作者Yurii Hrecheniuk