应测试构造函数初始化逻辑的正确性，而非new操作本身；重点验证属性赋值、方法可调用性、边界输入容错及this指向，避免无效断言如typeof new结果或instanceof检查。
直接对构造函数的实例化过程本身做单元测试，意义不大——因为 new 是 JavaScript 引擎内置行为，不可覆盖、无需验证是否“能创建对象”。真正该测的，是构造函数**初始化逻辑的正确性**：属性是否按预期赋值、方法是否可调用、边界输入是否被合理处理。
测构造函数的初始化逻辑
重点验证 this 上挂载的属性和方法是否符合设计意图，而不是测 new 是否生效。
- 传入合法参数时，实例应拥有正确的属性值（如
name、age） - 传入非法或缺失参数时，应有合理默认值或容错行为（如字符串转数字失败、
undefined处理） - 实例方法能正常执行，且内部
this指向正确，不报undefined错
避免测“new 是否工作”这类无效用例
下面这些测试没有实际价值，属于伪断言：
-
expect(typeof new Person()).toBe('object')——new总是返回对象（除非显式 return 对象），不反映业务逻辑 -
expect(new Person() instanceof Person).toBe(true)—— 这是语言机制保证的，不是你代码的逻辑责任 - 反复测
new Person('a', 25)能不能生成对象 —— 和测1 + 1 === 2一样，不解决任何工程问题
推荐的测试结构（以 Jest 为例）
聚焦行为，而非语法。例如对如下构造函数：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
function User(name, email) {
this.name = name?.trim() || 'Anonymous';
this.email = email?.toLowerCase().replace(/\s/g, '') || '';
this.getDisplayName = function() {
return this.email ? `${this.name} <${this.email}>` : this.name;
};
}
对应的有效测试应类似：
- 空 name →
name为'Anonymous' - 带空格的 email → 自动去空格并小写
-
getDisplayName()返回格式正确，且this在方法内可用 - 传入
null或undefined时不抛错
补充：若需验证原型链行为，单独测 prototype 方法
如果把方法定义在 Person.prototype 上（推荐做法），那就该单独写测试验证该方法逻辑，例如：
Person.prototype.sayHello = function() {
return `Hi, I'm ${this.name}`;
};
此时测试目标是：const p = new Person('Alice'); expect(p.sayHello()).toBe('Hi, I'm Alice'); —— 测的是方法行为，不是实例化动作。
