理解测试挑战
在 javascript 应用开发中，尤其是在构建 sdk 或需要与第三方库交互的场景下，我们经常会遇到代码直接依赖 window 对象上定义的全局属性或方法。例如，一个外部库 ats 可能通过 window.ats 提供服务：
private getFromATS(): string {
return window.ats.retrieveEnvelope(function (envelope: string) {
console.log('Located ATS.js');
return JSON.parse(envelope).envelope;
});
}当我们需要对包含此类依赖的代码进行单元测试时，问题便出现了。在没有实际加载 ats 库的环境下（如 Karma/Jasmine 测试），window.ats 将是 undefined，导致测试失败。传统的 Jasmine 模拟方法，如 spyOn，通常用于模拟对象上的现有方法，但对于 window 对象上可能不存在的属性或需要完全替换整个属性的情况，它们往往力不从心。尝试直接 spyOn(window, 'ats') 或使用 Object.defineProperty 可能会遇到各种限制或不符合预期。
Jasmine 中模拟 window 属性的策略
解决这一问题的最直接且有效的方法是，在每个测试用例或测试套件运行前，手动在 window 对象上定义或重写所需的属性，并在测试结束后将其清理。Jasmine 提供了 beforeEach 和 afterEach 钩子函数，非常适合实现这种设置（setup）和清理（teardown）逻辑。
核心思想：
- 在 beforeEach 中设置模拟对象： 在每个测试用例运行之前，将 window.ats 定义为一个包含模拟方法的对象。这样，当被测试的代码尝试访问 window.ats 时，它将使用我们提供的模拟版本。
- 在 afterEach 中清理模拟对象： 在每个测试用例运行之后，将 window.ats 恢复到其原始状态（例如，设置为 undefined 或删除该属性）。这确保了测试之间的隔离性，防止一个测试的副作用影响到后续的测试。
示例代码：
假设我们有一个 MySDK 类，其中包含 getFromATS 方法：
// src/my-sdk.ts
class MySDK {
public getFromATS(): string {
return window.ats.retrieveEnvelope(function (envelope: string) {
// 假设这里有一些日志或解析逻辑
return JSON.parse(envelope).envelope;
});
}
}
// 假设 Callback 是一个类型定义
type Callback = (data: T) => any;
// test/my-sdk.spec.ts
describe('MySDK', () => {
let mySdkInstance: MySDK;
beforeEach(() => {
// 实例化 MySDK
mySdkInstance = new MySDK();
// 在每个测试用例运行前，设置模拟的 window.ats 对象
// 模拟 retrieveEnvelope 方法，使其调用传入的回调函数并返回期望的数据
window.ats = {
retrieveEnvelope: function (callback: Callback) {
// 模拟外部库返回的 JSON 字符串
const mockEnvelopeJson = '{"envelope":"mocked_envelope_data_from_ats"}';
// 调用回调函数，并返回回调函数的结果，以匹配原始行为
return callback(mockEnvelopeJson);
},
};
});
afterEach(() => {
// 在每个测试用例运行后，清理模拟对象
// 将 window.ats 设置为 undefined，或者使用 delete 运算符彻底删除属性
window.ats = undefined;
// 或者：delete (window as any).ats;
});
it('should retrieve envelope from mocked window.ats', () => {
// 调用被测试的方法
const result = mySdkInstance.getFromATS();
// 验证结果是否符合模拟数据
expect(result).toBe('mocked_envelope_data_from_ats');
});
// 可以添加更多测试用例，它们都会在独立的模拟环境中运行
it('should handle different mocked data if needed', () => {
// 在这个测试用例中，可以重新定义 window.ats 来模拟不同的场景
window.ats = {
retrieveEnvelope: function (callback: Callback) {
return callback('{"envelope":"another_mocked_value"}');
},
};
const result = mySdkInstance.getFromATS();
expect(result).toBe('another_mocked_value');
});
}); 工作原理与优势
这种方法的有效性在于：
- 直接修改全局对象： 在浏览器或 Node.js 环境中，window（或 Node.js 中的 global）是一个可写的全局对象。在测试执行的上下文中，我们可以直接向其添加或修改属性。
- 作用域隔离： beforeEach 和 afterEach 钩子确保了这种修改只在当前测试用例或测试套件的生命周期内有效。每个测试用例在执行时都会获得一个“干净”的 window.ats 环境，从而避免了测试之间的相互干扰。
- 不侵入源代码： 这种方法不需要修改原始的 SDK 代码，这对于无法控制或不希望修改第三方库或现有代码库的场景非常有用。
注意事项
- 彻底清理： afterEach 中的清理步骤至关重要。如果忘记清理，前一个测试用例对 window 对象的修改可能会污染后续的测试用例，导致难以调试的测试失败。
- 全局污染的权衡： 尽管在测试环境中为了模拟目的修改全局对象是可接受的，但在实际应用代码中应尽量避免直接修改 window 对象，因为它可能导致全局污染和难以预测的行为。
- 替代方案： 依赖注入（Dependency Injection, DI）是一种更健壮的设计模式，它通过将依赖项作为参数传递或通过构造函数注入来解耦组件。如果项目允许修改源代码，采用依赖注入通常是更好的选择，因为它提高了代码的可测试性、可维护性和灵活性。然而，当无法修改源代码时，本文介绍的直接模拟方法是一个实用的解决方案。
总结
在 Karma 和 Jasmine 中测试依赖于 window 对象上外部库的代码时，直接在 beforeEach 中设置模拟的 window 属性，并在 afterEach 中进行清理，是一种简洁、高效且非侵入性的策略。它确保了测试环境的隔离性和可预测性，使得单元测试能够专注于验证核心业务逻辑，而无需关心外部依赖的实际存在。正确使用 beforeEach 和 afterEach，能够有效管理测试状态，编写出健壮可靠的单元测试。
