✗ npx jest --version
24.5.0
有一组对时区敏感的笑话测试。我们通常使用 npm 脚本运行它们："jest": "TZ=utc jest"
将 TZ 设置为 utc 后，我在快照中得到如下值：
modificationDate="2019-01-08T00:00:00.000Z"
没有它我得到：
modificationDate="2019-01-08T08:00:00.000Z"
有没有办法在我的 jest 配置中设置它，这样我就可以npx jest在命令行上运行而无需通过 NPM 脚本？配置文档中没有关于此的任何内容。
我尝试将这两个添加到我的 jest.config.js 中。没有一个工作：
TZ: 'utc',
globals: {
TZ: 'utc',
},
当然，解决这个问题似乎微不足道，但我很惊讶 Jest 没有办法为测试配置它。
这在节点 17.0.1 之前的 Windows 上不起作用- 请参阅https://github.com/nodejs/node/issues/4230
问题process.env.TZ = 'UTC';在于，如果在此行之前运行并使用Date了某些内容，则该值将被缓存在Date. 因此process.env一般不适合设置时区。见 https://github.com/nodejs/node/issues/3449
所以更好的方法是使用实际的 env 变量，但对于测试，这将起作用：
1. 将此添加到您的 package.json
"jest": {
...
// depending on your paths it can also be './global-setup.js'
"globalSetup": "../global-setup.js"
}
}
2.将这个文件之外的package.json为global-setup.js
module.exports = async () => {
process.env.TZ = 'UTC';
};
3. 可选：添加确保 UTC 执行的测试
describe('Timezones', () => {
it('should always be UTC', () => {
expect(new Date().getTimezoneOffset()).toBe(0);
});
});
正常setupFiles并不能正常工作对我来说，因为它们运行太晚了（开玩笑：^ 23.5.0）。所以必须使用 globalSetup 文件。
如果您使用 npm 脚本运行测试，即：npm run test，您可以像这样传入时区：
"scripts": {
"test": "TZ=UTC jest"
},
我个人也觉得这（与process.env方法相比）在调试远程 CI 服务器上的问题时更清晰，更容易识别时区。
我刚刚遇到了同样的问题，我能够通过添加process.env.TZ = 'your/timezone';到我的jest.config.js.
也许这对您的情况也有帮助:)
process.env.TZ = 'UTC';
module.exports = {
...
};
更新：如果您想动态更改 TZ，这不会产生确定性结果，但如果您只想要一个 TZ，它会起作用。它可能是在脚本级别指定的替代方法，但我认为这将是更好的答案。
问题在于，通过process.env.TZ在运行时设置，它会在常规 Jest 测试运行期间跨测试产生不确定性行为（副作用）。如果您使用which 串行运行测试，它可能会起作用--runInBand，但我不会指望它。
我还发现了一个关于 Node 中动态时区的旧存档问题，看起来动态调整它通常不起作用。
相反，我可能最终会得到多个脚本，每个脚本都TZ在启动之前设置jest。
对于我的用例，我实际上想在不同时区下针对特定的基于日期的边缘情况运行测试。有时用户会遇到基于时区的错误，我们希望在我们的测试套件中轻松覆盖。
我们默认使用此处建议的答案之一运行项目中的所有测试，通过TZ=UTC在npm脚本中设置（例如TZ=UTC npm run jest。这将在 UTC 时区下运行所有测试。
然后，我们利用testEnvironment可以使用 JSDoc pragma在测试套件级别设置的配置@jest-environment。使用此自定义测试环境，然后我们可以使用“自定义文档块编译指示”（如@timezone. 这使每个测试套件的时区自定义成为可能，这不像每个测试那样理想，但足以满足我们的目的。
jsdom-with-timezone.js
const JSDOMEnvironment = require('jest-environment-jsdom');
/**
* Timezone-aware jsdom Jest environment. Supports `@timezone` JSDoc
* pragma within test suites to set timezone.
*
* You'd make another copy of this extending the Node environment,
* if needed for Node server environment-based tests.
*/
module.exports = class TimezoneAwareJSDOMEnvironment extends JSDOMEnvironment
{
constructor(config, context) {
// Allow test suites to change timezone, even if TZ is passed in a script.
// Falls back to existing TZ environment variable or UTC if no timezone is specified.
// IMPORTANT: This must happen before super(config) is called, otherwise
// it doesn't work.
process.env.TZ = context.docblockPragmas.timezone || process.env.TZ || 'UTC';
super(config);
}
};
tz-eastern.test.js
/**
* @timezone America/New_York
*/
describe('timezone: eastern', () => {
it('should be America/New_York timezone', () => {
expect(process.env.TZ).toBe('America/New_York');
expect(new Date().getTimezoneOffset()).toBe(300 /* 5 hours */);
});
});
开玩笑的配置文件
module.exports = {
"testEnvironment": "<rootDir>/jsdom-with-timezone.js"
}
使用它jest.useFakeTimers('modern');并jest.setSystemTime()足以进行更强大的日期测试，所以我想我会分享这种方法让其他人从中受益！由于 pragma 处理是自定义的，您可以为您的用例以任何您喜欢的方式自定义它。
资料来源：
直到最近，我使用以下内容来模拟处于不同的时区：
beforeEach(() => {
// Temporarily allow us to alter timezone calculation for testing
/*eslint no-extend-native: "off"*/
Date.prototype.getTimezoneOffset = jest.fn(() => 73);
});
afterEach(() => {
jest.resetAllMocks();
});
这并没有将测试代码放在特定的时区，而是确保任何时区偏移计算都正确进行。例如：
new Date("2010-10-01")将比 早 73 分钟new Date("2010-10-01T00:00:00")，前者相当于new Date("2010-10-01T00:00:00Z")（UTC 时区），后者在“本地时区”中
我说“直到最近”，因为最近对 date-fns 的更新似乎不再有效