使用require编写NodeJS单元测试时引入含import的NestJS服务报SyntaxError

当前报错和测试文件本身使用require还是import没有关联，核心原因是 原生Node.js运行环境没有内置TypeScript语法、ES Module语法的转译能力。你直接require后缀为.ts的业务源文件时，Node没有经过任何转译步骤就直接解析文件内容，碰到文件里的import语句、TypeScript装饰器（比如@Injectable）时，自然会抛出Unexpected token的语法错误。
另外你当前的mock实现逻辑也存在偏差：单元测试场景下不需要初始化真实TypeORM连接、获取真实Repository实例，否则会把单元测试耦合上数据库依赖，既降低测试运行效率，又容易造成全局状态污染。

1. 为测试环境补全TypeScript转译能力 #

只要解决了TS文件的加载转译问题，语法报错就会完全消失，结合你当前的技术栈有两种适配性很高的实现方式：

• 方式一：使用NestJS生态默认的Jest测试运行器
  • 在项目的jest.config配置中指定ts-jest作为转译器，Jest会自动完成所有.ts文件的语法转译，不管是测试文件还是被引入的业务源文件，碰到import、装饰器等语法都会自动转换为Node可识别的CommonJS格式，不会触发语法报错。
  • 这套配置下你可以完全保留原有的Chai断言、Sinon mock的使用习惯，不需要强制改用Jest自带的断言和mock能力。
• 方式二：保留现有Mocha+Chai+Sinon的测试组合
  • 启动测试流程时，加上ts-node的转译注册钩子，启动命令示例：mocha -r ts-node/register 'test/**/*.spec.ts'。Node加载.ts文件时会自动调用ts-node完成实时转译，同样可以解决原生Node解析不了TS语法的问题。

2. 修正Repository的mock实现逻辑 #

就算语法问题解决，你当前调用typeorm.getRepository(Device)的写法需要初始化完整的TypeORM数据库连接，既拖慢测试速度，又容易造成测试用例之间的状态污染。单元测试只需要保证mock对象的方法形状和真实Repository的接口完全匹配即可，完全不需要获取真实的Repository实例：

• 替换原有的stub逻辑为手动构造假Repository，示例代码：

  // 不需要调用typeorm.getRepository初始化连接，直接构造符合依赖形状的mock对象
  const mockDeviceRepo = {
    create: sinon.stub().returns(mockCreateReturn),
    save: sinon.stub(),
    findOne: sinon.stub()
  }
  // 直接将mock对象作为依赖传入服务构造函数，和服务实际运行时获取的依赖结构完全一致
  const testDeviceService = new DeviceService(mockDeviceRepo)
  

• 这种方式完全隔离了数据库依赖，测试运行速度快，也不会出现stub全局方法造成的跨用例污染问题。

3. 修正认知偏差 #

“测试文件中不能使用import语法”的判断并不准确：只要测试环境配置了正确的TS转译流程，测试文件里不管写import还是require，都可以正常运行。当前的报错本质是未经过转译的业务TS源文件被原生Node直接加载，和测试文件本身使用哪种模块语法没有任何关联。

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