Expect 断言
想了解由 Jest 社区维护的其他 Jest 匹配器,请查看 jest-extended
- expect(value)
- expect.anything()
- expect.arrayContaining(array)
- expect.closeTo(number, numDigits?)
- expect.not.arrayContaining(array)
- expect.not.stringContaining(string)
- expect.objectContaining(object)
- expect.stringMatching(string | regexp)
- .not
- .rejects
- .toHaveBeenCalled()
- .toHaveBeenCalledWith(arg1, arg2, …)
- .toHaveBeenNthCalledWith(nthCall, arg1, arg2, ….)
- .toHaveReturnedTimes(number)
- .toHaveLastReturnedWith(value)
- .toHaveLength(number)
- .toBeCloseTo(number, numDigits?)
- .toBeFalsy()
- .toBeGreaterThanOrEqual(number | bigint)
- .toBeLessThanOrEqual(number | bigint)
- .toBeNull()
- .toBeUndefined()
- .toContain(item)
- .toEqual(value)
- .toMatchObject(object)
- .toMatchInlineSnapshot(propertyMatchers?, inlineSnapshot)
- .toThrow(error?)
- .toThrowErrorMatchingInlineSnapshot(inlineSnapshot)
参考
判断一个值是否满足条件,你会使用到expect
函数。 但你很少会单独调用expect
函数, 因为你通常会结合expect
和匹配器函数来断言某个值。
下面是一个很容易理解的例子: 假设你有一个方法bestLaCroixFlavor()
,它应该返回字符串'grapefruit'
。 下面是如何测试:
上述代码里的 toBe
就是我们所说的匹配器函数, 本篇文档下面的部分提供了很多不同的匹配器函数,了解它们可以帮助你测试更多不同的内容。
expect
的参数应该是被测代码的返回值,而匹配器接收的传入参数则是希望被测代码返回的值。 如果你将它们混合使用,你的测试仍然可以执行,但是测试失败的错误信息看起来会比较奇怪。
expect.extend(matchers)
使用expect.extend
添加自定义的匹配器函数。 例如,你正在测试一个处理 number 的工具库,并且你经常地断言某个数字是否在一个范围之内。 你就可以将它抽象为一个匹配器函数,叫toBeDivisibleBy
:
// 添加自定义的匹配器
expect.extend({
toBeWithinRange(received, floor, ceiling) {
const pass = received >= floor && received <= ceiling;
if (pass) {
return {
message: () =>
`expected ${received} not to be within range ${floor} - ${ceiling}`,
pass: true,
};
} else {
return {
message: () =>
`expected ${received} to be within range ${floor} - ${ceiling}`,
pass: false,
};
}
},
});
// 使用已经添加的匹配器
test('numeric ranges', () => {
expect(100).toBeWithinRange(90, 110);
expect(101).not.toBeWithinRange(0, 100);
expect({apples: 6, bananas: 3}).toEqual({
apples: expect.toBeWithinRange(1, 10),
bananas: expect.not.toBeWithinRange(11, 20),
});
});
note
注意:在 TypeScript 中,当使用 @types/jest
作为类型时,你可以在导入的模块中声明新的 toBeWithinrange
匹配器,如:
interface CustomMatchers<R = unknown> {
toBeWithinRange(floor: number, ceiling: number): R;
}
declare global {
namespace jest {
interface Expect extends CustomMatchers {}
interface Matchers<R> extends CustomMatchers<R> {}
interface InverseAsymmetricMatchers extends CustomMatchers {}
}
}
异步 Matcher
expect.extension
也支持异步 Matcher。 异步匹配器返回了一个 Promise,因此您需要 await 返回值。 接下来我们给出一个例子来说明其用法。 我们将实现一个叫做 toBevisibleByExternalValue
的 Matcher,在这个Matcher 中,可被外部值整除的值将被通过。
expect.extend({
async toBeDivisibleByExternalValue(received) {
const externalValue = await getExternalValueFromRemoteSource();
const pass = received % externalValue == 0;
if (pass) {
return {
message: () =>
`expected ${received} not to be divisible by ${externalValue}`,
pass: true,
};
} else {
return {
message: () =>
`expected ${received} to be divisible by ${externalValue}`,
pass: false,
};
}
},
});
test('is divisible by external value', async () => {
await expect(100).toBeDivisibleByExternalValue();
await expect(101).not.toBeDivisibleByExternalValue();
});
自定义 Matcher API
Matcher 应该返回一个拥有 2 个属性的 object(或者返回一个 Promise,其返回值为拥有 2 个属性的 obect)。 pass
表示是否匹配到,而 message
提供了一个没有参数的函数,在出现故障的情况下返回错误消息。 因此,当pass
为false时,message
应该返回当expect(x).yourMatcher()
失败时的错误消息。 而当pass
为true时, message
应该返回当expect(x).not.yourMatcher()
失败时的错误信息。
Matcher 被时,收到的第一个参数为 expect(x)
中的 x
,第二、三个参数分别为 .yourMatcher(y, z)
中的 y
、z
expect.extend({
yourMatcher(x, y, z) {
return {
pass: true,
message: () => '',
};
},
});
在自定义 Matcher 中,可以通过 this
来访问下列帮助函数与属性:
this.isNot
一个布尔值,可以让你知道这个 matcher 之前是否调用了表示否定的 .not
修饰符,以便你提供给用户一个比较清晰和正确的 matcher 提示(参见示例代码)。
this.promise
一个字符串允许您显示一个清晰和正确的匹配器提示:
'reject'
如果 matcher 被 Promise中的.rejects
所调用'resolves'
如果 matcher 被 Promise中的.resolves
所调用''
如果 matcher 没有被 Promise 修饰符调用
this.equals(a, b)
A boolean to let you know this matcher was called with an expand
option. When Jest is called with the --expand
flag, this.expand
can be used to determine if Jest is expected to show full diffs and errors.
this.expand
A boolean to let you know this matcher was called with an expand
option. When Jest is called with the --expand
flag, this.expand
can be used to determine if Jest is expected to show full diffs and errors.
this.utils
There are a number of helpful tools exposed on this.utils
primarily consisting of the exports from .
The most useful ones are matcherHint
, printExpected
and printReceived
to format the error messages nicely. For example, take a look at the implementation for the toBe
matcher:
const {diff} = require('jest-diff');
expect.extend({
toBe(received, expected) {
const options = {
comment: 'Object.is equality',
isNot: this.isNot,
promise: this.promise,
};
const pass = Object.is(received, expected);
const message = pass
? () =>
// eslint-disable-next-line prefer-template
this.utils.matcherHint('toBe', undefined, undefined, options) +
'\n\n' +
`Expected: not ${this.utils.printExpected(expected)}\n` +
`Received: ${this.utils.printReceived(received)}`
: () => {
const diffString = diff(expected, received, {
expand: this.expand,
});
return (
// eslint-disable-next-line prefer-template
this.utils.matcherHint('toBe', undefined, undefined, options) +
'\n\n' +
(diffString && diffString.includes('- Expect')
? `Difference:\n\n${diffString}`
: `Expected: ${this.utils.printExpected(expected)}\n` +
`Received: ${this.utils.printReceived(received)}`)
);
};
return {actual: received, message, pass};
},
});
This will print something like this:
expect(received).toBe(expected)
Expected value to be (using Object.is):
"banana"
Received:
"apple"
When an assertion fails, the error message should give as much signal as necessary to the user so they can resolve their issue quickly. You should craft a precise failure message to make sure users of your custom assertions have a good developer experience. You should craft a precise failure message to make sure users of your custom assertions have a good developer experience.
自定义快照匹配器
To use snapshot testing inside of your custom matcher you can import jest-snapshot
and use it from within your matcher.
Here’s a snapshot matcher that trims a string to store for a given length, .toMatchTrimmedSnapshot(length)
:
const {toMatchSnapshot} = require('jest-snapshot');
expect.extend({
toMatchTrimmedSnapshot(received, length) {
return toMatchSnapshot.call(
this,
received.substring(0, length),
'toMatchTrimmedSnapshot',
);
},
});
it('stores only 10 characters', () => {
expect('extra long string oh my gerd').toMatchTrimmedSnapshot(10);
});
/*
Stored snapshot will look like:
exports[`stores only 10 characters: toMatchTrimmedSnapshot 1`] = `"extra long"`;
*/
It’s also possible to create custom matchers for inline snapshots, the snapshots will be correctly added to the custom matchers. It’s also possible to create custom matchers for inline snapshots, the snapshots will be correctly added to the custom matchers. However, inline snapshot will always try to append to the first argument or the second when the first argument is the property matcher, so it’s not possible to accept custom arguments in the custom matchers.
const {toMatchInlineSnapshot} = require('jest-snapshot');
expect.extend({
toMatchTrimmedInlineSnapshot(received, ...rest) {
return toMatchInlineSnapshot.call(this, received.substring(0, 10), ...rest);
},
});
it('stores only 10 characters', () => {
expect('extra long string oh my gerd').toMatchTrimmedInlineSnapshot();
/*
The snapshot will be added inline like
expect('extra long string oh my gerd').toMatchTrimmedInlineSnapshot(
`"extra long"`
);
*/
});
异步
If your custom inline snapshot matcher is async i.e. uses async
-await
you might encounter an error like “Multiple inline snapshots for the same call are not supported”. Jest needs additional context information to find where the custom inline snapshot matcher was used to update the snapshots properly.
const {toMatchInlineSnapshot} = require('jest-snapshot');
async toMatchObservationInlineSnapshot(fn, ...rest) {
// The error (and its stacktrace) must be created before any `await`
this.error = new Error();
// The implementation of `observe` doesn't matter.
// It only matters that the custom snapshot matcher is async.
const observation = await observe(async () => {
await fn();
});
return toMatchInlineSnapshot.call(this, recording, ...rest);
},
});
it('observes something', async () => {
await expect(async () => {
return 'async action';
}).toMatchTrimmedInlineSnapshot();
/*
The snapshot will be added inline like
await expect(async () => {
return 'async action';
}).toMatchTrimmedInlineSnapshot(`"async action"`);
*/
});
Bail out
Usually jest
tries to match every snapshot that is expected in a test.
Sometimes it might not make sense to continue the test if a prior snapshot failed. For example, when you make snapshots of a state-machine after various transitions you can abort the test once one transition produced the wrong state.
In that case you can implement a custom snapshot matcher that throws on the first mismatch instead of collecting every mismatch.
const {toMatchInlineSnapshot} = require('jest-snapshot');
expect.extend({
toMatchStateInlineSnapshot(...args) {
this.dontThrow = () => {};
return toMatchInlineSnapshot.call(this, ...args);
},
});
let state = 'initial';
function transition() {
// Typo in the implementation should cause the test to fail
if (state === 'INITIAL') {
state = 'pending';
} else if (state === 'pending') {
state = 'done';
}
}
it('transitions as expected', () => {
expect(state).toMatchStateInlineSnapshot(`"initial"`);
transition();
// Already produces a mismatch. No point in continuing the test.
expect(state).toMatchStateInlineSnapshot(`"loading"`);
transition();
expect(state).toMatchStateInlineSnapshot(`"done"`);
});
expect.anything()
expect.anything()
matches anything but null
or undefined
. You can use it inside toEqual
or toBeCalledWith
instead of a literal value. For example, if you want to check that a mock function is called with a non-null argument: You can use it inside toEqual
or toBeCalledWith
instead of a literal value. For example, if you want to check that a mock function is called with a non-null argument:
test('map calls its argument with a non-null argument', () => {
const mock = jest.fn();
[1].map(x => mock(x));
expect(mock).toBeCalledWith(expect.anything());
});
expect.any(constructor)
expect.any(constructor)
匹配任何被给定的构造函数所创建的东西,或者如果它是原始值的传递类型。 You can use it inside toEqual
or toBeCalledWith
instead of a literal value. For example, if you want to check that a mock function is called with a number:
class Cat {}
function getCat(fn) {
return fn(new Cat());
}
test('randocall calls its callback with a class instance', () => {
const mock = jest.fn();
getCat(mock);
expect(mock).toBeCalledWith(expect.any(Cat));
});
function randocall(fn) {
return fn(Math.floor(Math.random() * 6 + 1));
}
test('randocall calls its callback with a number', () => {
const mock = jest.fn();
randocall(mock);
expect(mock).toBeCalledWith(expect.any(Number));
});
expect.arrayContaining(array)
expect.arrayContaining(array)
matches a received array which contains all of the elements in the expected array. That is, the expected array is a subset of the received array. Therefore, it matches a received array which contains elements that are not in the expected array. That is, the expected array is a subset of the received array. Therefore, it matches a received array which contains elements that are not in the expected array.
You can use it instead of a literal value:
- 在
toEqual
或toBecaledwith
- to match a property in
objectContaining
ortoMatchObject
describe('arrayContaining', () => {
const expected = ['Alice', 'Bob'];
it('matches even if received contains additional elements', () => {
expect(['Alice', 'Bob', 'Eve']).toEqual(expect.arrayContaining(expected));
});
it('does not match if received does not contain expected elements', () => {
expect(['Bob', 'Eve']).not.toEqual(expect.arrayContaining(expected));
});
});
describe('Beware of a misunderstanding! describe('Beware of a misunderstanding! A sequence of dice rolls', () => {
const expected = [1, 2, 3, 4, 5, 6];
it('matches even with an unexpected number 7', () => {
expect([4, 1, 6, 7, 3, 5, 2, 5, 4, 6]).toEqual(
expect.arrayContaining(expected),
);
});
it('does not match without an expected number 2', () => {
expect([4, 1, 6, 7, 3, 5, 7, 5, 4, 6]).not.toEqual(
);
});
});
expect.assertions(number)
expect.assertions(number)
verifies that a certain number of assertions are called during a test. This is often useful when testing asynchronous code, in order to make sure that assertions in a callback actually got called. This is often useful when testing asynchronous code, in order to make sure that assertions in a callback actually got called.
For example, let’s say that we have a function doAsync
that receives two callbacks callback1
and callback2
, it will asynchronously call both of them in an unknown order. We can test this with: We can test this with:
test('doAsync calls both callbacks', () => {
expect.assertions(2);
function callback1(data) {
expect(data).toBeTruthy();
}
function callback2(data) {
expect(data).toBeTruthy();
}
doAsync(callback1, callback2);
});
The expect.assertions(2)
call ensures that both callbacks actually get called.
expect.closeTo(number, numDigits?)
expect.closeTo(number, numDigits?)
is useful when comparing floating point numbers in object properties or array item. If you need to compare a number, please use .toBeCloseTo
instead.
The optional numDigits
argument limits the number of digits to check after the decimal point. For the default value 2
, the test criterion is Math.abs(expected - received) < 0.005 (that is, 10 ** -2 / 2)
.
For example, this test passes with a precision of 5 digits:
test('compare float in object properties', () => {
expect({
title: '0.1 + 0.2',
sum: 0.1 + 0.2,
}).toEqual({
title: '0.1 + 0.2',
sum: expect.closeTo(0.3, 5),
});
});
expect.hasAssertions()
expect.hasAssertions()
verifies that at least one assertion is called during a test. This is often useful when testing asynchronous code, in order to make sure that assertions in a callback actually got called. This is often useful when testing asynchronous code, in order to make sure that assertions in a callback actually got called.
For example, let’s say that we have a few functions that all deal with state. For example, let’s say that we have a few functions that all deal with state. prepareState
calls a callback with a state object, validateState
runs on that state object, and waitOnState
returns a promise that waits until all prepareState
callbacks complete. We can test this with: We can test this with:
test('prepareState prepares a valid state', () => {
expect.hasAssertions();
prepareState(state => {
expect(validateState(state)).toBeTruthy();
});
return waitOnState();
});
The expect.hasAssertions()
call ensures that the prepareState
callback actually gets called.
expect.not.arrayContaining(array)
expect.not.arrayContaining(array)
matches a received array which does not contain all of the elements in the expected array. That is, the expected array is not a subset of the received array. That is, the expected array is not a subset of the received array.
It is the inverse of expect.arrayContaining
.
describe('not.arrayContaining', () => {
const expected = ['Samantha'];
it('matches if the actual array does not contain the expected elements', () => {
expect(['Alice', 'Bob', 'Eve']).toEqual(
expect.not.arrayContaining(expected),
);
});
});
expect.not.objectContaining(object)
expect.not.objectContaining(object)
matches any received object that does not recursively match the expected properties. That is, the expected object is not a subset of the received object. Therefore, it matches a received object which contains properties that are not in the expected object. That is, the expected object is not a subset of the received object. Therefore, it matches a received object which contains properties that are not in the expected object.
It is the inverse of expect.objectContaining
.
describe('not.objectContaining', () => {
const expected = {foo: 'bar'};
it('matches if the actual object does not contain expected key: value pairs', () => {
expect({bar: 'baz'}).toEqual(expect.not.objectContaining(expected));
});
});
expect.not.stringContaining(string)
expect.not.stringContaining(string)
matches the received value if it is not a string or if it is a string that does not contain the exact expected string.
It is the inverse of expect.stringContaining
.
describe('not.stringContaining', () => {
const expected = 'Hello world!';
it('matches if the received value does not contain the expected substring', () => {
expect('How are you?').toEqual(expect.not.stringContaining(expected));
});
});
expect.not.stringMatching(string | regexp)
expect.not.stringMatching(string | regexp)
matches the received value if it is not a string or if it is a string that does not match the expected string or regular expression.
It is the inverse of expect.stringMatching
.
describe('not.stringMatching', () => {
const expected = /Hello world!/;
it('matches if the received value does not match the expected regex', () => {
expect('How are you?').toEqual(expect.not.stringMatching(expected));
});
});
expect.objectContaining(object)
expect.objectContaining(object)
matches any received object that recursively matches the expected properties. That is, the expected object is a subset of the received object. expect.objectContaining(object)
matches any received object that recursively matches the expected properties. That is, the expected object is a subset of the received object. Therefore, it matches a received object which contains properties that are present in the expected object.
Instead of literal property values in the expected object, you can use matchers, expect.anything()
, and so on.
For example, let’s say that we expect an onPress
function to be called with an Event
object, and all we need to verify is that the event has event.x
and event.y
properties. We can do that with: We can do that with:
test('onPress gets called with the right thing', () => {
const onPress = jest.fn();
simulatePresses(onPress);
expect(onPress).toBeCalledWith(
expect.objectContaining({
x: expect.any(Number),
y: expect.any(Number),
}),
);
});
expect.stringContaining(string)
expect.stringContaining(string)
matches the received value if it is a string that contains the exact expected string.
expect.stringMatching(string | regexp)
expect.stringMatching(string | regexp)
matches the received value if it is a string that matches the expected string or regular expression.
You can use it instead of a literal value:
- 在
toEqual
或toBecaledwith
- to match an element in
arrayContaining
- to match a property in
objectContaining
ortoMatchObject
This example also shows how you can nest multiple asymmetric matchers, with expect.stringMatching
inside the expect.arrayContaining
.
describe('stringMatching in arrayContaining', () => {
const expected = [
expect.stringMatching(/^Alic/),
expect.stringMatching(/^[BR]ob/),
];
it('matches even if received contains additional elements', () => {
expect(['Alicia', 'Roberto', 'Evelina']).toEqual(
expect.arrayContaining(expected),
);
});
it('does not match if received does not contain expected elements', () => {
expect(['Roberto', 'Evelina']).not.toEqual(
expect.arrayContaining(expected),
);
});
});
expect.addSnapshotSerializer(serializer)
You can call expect.addSnapshotSerializer
to add a module that formats application-specific data structures.
If you add a snapshot serializer in individual test files instead of adding it to snapshotSerializers
configuration:
- You make the dependency explicit instead of implicit.
- You avoid limits to configuration that might cause you to eject from .
See configuring Jest for more information.
.not
If you know how to test something, .not
lets you test its opposite. For example, this code tests that the best La Croix flavor is not coconut: For example, this code tests that the best La Croix flavor is not coconut:
test('the best flavor is not coconut', () => {
expect(bestLaCroixFlavor()).not.toBe('coconut');
});
.resolves
Use resolves
to unwrap the value of a fulfilled promise so any other matcher can be chained. If the promise is rejected the assertion fails. If the promise is rejected the assertion fails.
For example, this code tests that the promise resolves and that the resulting value is 'lemon'
:
test('resolves to lemon', () => {
// make sure to add a return statement
return expect(Promise.resolve('lemon')).resolves.toBe('lemon');
});
Note that, since you are still testing promises, the test is still asynchronous. Note that, since you are still testing promises, the test is still asynchronous. Hence, you will need to by returning the unwrapped assertion.
Alternatively, you can use async/await
in combination with .resolves
:
test('resolves to lemon', async () => {
await expect(Promise.resolve('lemon')).resolves.toBe('lemon');
await expect(Promise.resolve('lemon')).resolves.not.toBe('octopus');
});
Use .rejects
to unwrap the reason of a rejected promise so any other matcher can be chained. If the promise is fulfilled the assertion fails. If the promise is fulfilled the assertion fails.
For example, this code tests that the promise rejects with reason 'octopus'
:
test('rejects to octopus', () => {
// make sure to add a return statement
return expect(Promise.reject(new Error('octopus'))).rejects.toThrow(
'octopus',
);
});
Note that, since you are still testing promises, the test is still asynchronous. Note that, since you are still testing promises, the test is still asynchronous. Hence, you will need to by returning the unwrapped assertion.
Alternatively, you can use async/await
in combination with .rejects
.
test('rejects to octopus', async () => {
await expect(Promise.reject(new Error('octopus'))).rejects.toThrow('octopus');
});
.toBe(value)
Use .toBe
to compare primitive values or to check referential identity of object instances. It calls Object.is
to compare values, which is even better for testing than ===
strict equality operator.
For example, this code will validate some properties of the can
object:
const can = {
name: 'pamplemousse',
ounces: 12,
};
describe('the can', () => {
test('has 12 ounces', () => {
expect(can.ounces).toBe(12);
});
test('has a sophisticated name', () => {
expect(can.name).toBe('pamplemousse');
});
});
Don’t use .toBe
with floating-point numbers. For example, due to rounding, in JavaScript 0.2 + 0.1
is not strictly equal to 0.3
. Don’t use .toBe
with floating-point numbers. For example, due to rounding, in JavaScript 0.2 + 0.1
is not strictly equal to 0.3
. If you have floating point numbers, try .toBeCloseTo
instead.
Although the .toBe
matcher checks referential identity, it reports a deep comparison of values if the assertion fails. If differences between properties do not help you to understand why a test fails, especially if the report is large, then you might move the comparison into the expect
function. For example, to assert whether or not elements are the same instance: If differences between properties do not help you to understand why a test fails, especially if the report is large, then you might move the comparison into the expect
function. For example, use equals
method of Buffer
class to assert whether or not buffers contain the same content: For example, to assert whether or not elements are the same instance:
- 使用
expect(Object.is(received, expected)).toBe(true)
代替expect(received).toBe(expected)
- 使用
expect(Object.is(received, expected)).toBe(false)
代替expect(received).not.toBe(expected)
.toHaveBeenCalled()
Also under the alias: .toBeCalled()
Use .toHaveBeenCalledWith
to ensure that a mock function was called with specific arguments. The arguments are checked with the same algorithm that .toEqual
uses.
For example, let’s say you have a drinkAll(drink, flavour)
function that takes a drink
function and applies it to all available beverages. For example, let’s say you have a drinkAll(drink, flavour)
function that takes a drink
function and applies it to all available beverages. You might want to check that drink
gets called for 'lemon'
, but not for 'octopus'
, because 'octopus'
flavour is really weird and why would anything be octopus-flavoured? You can do that with this test suite: You can do that with this test suite:
function drinkAll(callback, flavour) {
if (flavour !== 'octopus') {
callback(flavour);
}
}
describe('drinkAll', () => {
test('drinks something lemon-flavoured', () => {
const drink = jest.fn();
drinkAll(drink, 'lemon');
expect(drink).toHaveBeenCalled();
});
test('does not drink something octopus-flavoured', () => {
const drink = jest.fn();
drinkAll(drink, 'octopus');
expect(drink).not.toHaveBeenCalled();
});
});
.toHaveBeenCalledTimes(number)
Also under the alias: .toBeCalledTimes(number)
Use .toHaveBeenCalledTimes
to ensure that a mock function got called exact number of times.
For example, let’s say you have a drinkEach(drink, Array<flavor>)
function that takes a drink
function and applies it to array of passed beverages. You might want to check that drink function was called exact number of times. You can do that with this test suite: You might want to check that drink function was called exact number of times. You can do that with this test suite:
test('drinkEach drinks each drink', () => {
const drink = jest.fn();
drinkEach(drink, ['lemon', 'octopus']);
expect(drink).toHaveBeenCalledTimes(2);
});
.toHaveBeenCalledWith(arg1, arg2, ...)
Also under the alias: .toBeCalledWith()
Use .toHaveBeenCalledWith
to ensure that a mock function was called with specific arguments. The arguments are checked with the same algorithm that .toEqual
uses.
For example, let’s say that you can register a beverage with a register
function, and applyToAll(f)
should apply the function f
to all registered beverages. To make sure this works, you could write: To make sure this works, you could write:
test('registration applies correctly to orange La Croix', () => {
const beverage = new LaCroix('orange');
register(beverage);
const f = jest.fn();
applyToAll(f);
expect(f).toHaveBeenCalledWith(beverage);
});
.toHaveBeenLastCalledWith(arg1, arg2, ...)
Also under the alias: .lastCalledWith(arg1, arg2, ...)
If you have a mock function, you can use .toHaveBeenLastCalledWith
to test what arguments it was last called with. For example, let’s say you have a applyToAllFlavors(f)
function that applies f
to a bunch of flavors, and you want to ensure that when you call it, the last flavor it operates on is 'mango'
. You can write: For example, let’s say you have a applyToAllFlavors(f)
function that applies f
to a bunch of flavors, and you want to ensure that when you call it, the last flavor it operates on is 'mango'
. You can write:
test('applying to all flavors does mango last', () => {
const drink = jest.fn();
applyToAllFlavors(drink);
expect(drink).toHaveBeenLastCalledWith('mango');
});
.toHaveBeenNthCalledWith(nthCall, arg1, arg2, ....)
Also under the alias: .nthCalledWith(nthCall, arg1, arg2, ...)
If you have a mock function, you can use .toHaveBeenNthCalledWith
to test what arguments it was nth called with. For example, let’s say you have a drinkEach(drink, Array<flavor>)
function that applies f
to a bunch of flavors, and you want to ensure that when you call it, the first flavor it operates on is 'lemon'
and the second one is 'octopus'
. You can write:
test('drinkEach drinks each drink', () => {
const drink = jest.fn();
drinkEach(drink, ['lemon', 'octopus']);
expect(drink).toHaveBeenNthCalledWith(1, 'lemon');
expect(drink).toHaveBeenNthCalledWith(2, 'octopus');
});
note
第 n 个参数必须是从1开始的正整数
.toHaveReturned()
Also under the alias: .toReturn()
If you have a mock function, you can use .toHaveReturned
to test that the mock function successfully returned (i.e., did not throw an error) at least one time. For example, let’s say you have a mock drink
that returns true
. You can write: For example, let’s say you have a mock drink
that returns true
. You can write:
test('drinks returns', () => {
const drink = jest.fn(() => true);
drink();
expect(drink).toHaveReturned();
});
.toHaveReturnedTimes(number)
Also under the alias: .toReturnTimes(number)
Use .toHaveReturnedTimes
to ensure that a mock function returned successfully (i.e., did not throw an error) an exact number of times. Any calls to the mock function that throw an error are not counted toward the number of times the function returned. Any calls to the mock function that throw an error are not counted toward the number of times the function returned.
For example, let’s say you have a mock drink
that returns true
. You can write:
test('drink returns twice', () => {
drink();
drink();
expect(drink).toHaveReturnedTimes(2);
});
.toHaveReturnedWith(value)
Also under the alias: .toReturnWith(value)
Use .toHaveReturnedWith
to ensure that a mock function returned a specific value.
For example, let’s say you have a mock drink
that returns the name of the beverage that was consumed. You can write: You can write:
test('drink returns La Croix', () => {
const beverage = {name: 'La Croix'};
const drink = jest.fn(beverage => beverage.name);
drink(beverage);
expect(drink).toHaveReturnedWith('La Croix');
});
.toHaveLastReturnedWith(value)
Also under the alias: .lastReturnedWith(value)
Use .toHaveLastReturnedWith
to test the specific value that a mock function last returned. Use .toHaveLastReturnedWith
to test the specific value that a mock function last returned. If the last call to the mock function threw an error, then this matcher will fail no matter what value you provided as the expected return value.
For example, let’s say you have a mock drink
that returns the name of the beverage that was consumed. You can write: You can write:
test('drink returns La Croix (Orange) last', () => {
const beverage1 = {name: 'La Croix (Lemon)'};
const beverage2 = {name: 'La Croix (Orange)'};
const drink = jest.fn(beverage => beverage.name);
drink(beverage1);
drink(beverage2);
expect(drink).toHaveLastReturnedWith('La Croix (Orange)');
});
.toHaveNthReturnedWith(nthCall, value)
Also under the alias: .nthReturnedWith(nthCall, value)
Use .toHaveNthReturnedWith
to test the specific value that a mock function returned for the nth call. Use .toHaveNthReturnedWith
to test the specific value that a mock function returned for the nth call. If the nth call to the mock function threw an error, then this matcher will fail no matter what value you provided as the expected return value.
For example, let’s say you have a mock drink
that returns the name of the beverage that was consumed. You can write: You can write:
test('drink returns expected nth calls', () => {
const beverage1 = {name: 'La Croix (Lemon)'};
const beverage2 = {name: 'La Croix (Orange)'};
const drink = jest.fn(beverage => beverage.name);
drink(beverage1);
drink(beverage2);
expect(drink).toHaveNthReturnedWith(1, 'La Croix (Lemon)');
expect(drink).toHaveNthReturnedWith(2, 'La Croix (Orange)');
});
note
第 n 个参数必须是从1开始的正整数
.toHaveLength(number)
Use .toHaveLength
to check that an object has a .length
property and it is set to a certain numeric value.
This is especially useful for checking arrays or strings size.
expect([1, 2, 3]).toHaveLength(3);
expect('abc').toHaveLength(3);
expect('').not.toHaveLength(5);
.toHaveProperty(keyPath, value?)
Use .toHaveProperty
to check if property at provided reference keyPath
exists for an object. Use .toHaveProperty
to check if property at provided reference keyPath
exists for an object. For checking deeply nested properties in an object you may use or an array containing the keyPath for deep references.
You can provide an optional value
argument to compare the received property value (recursively for all properties of object instances, also known as deep equality, like the toEqual
matcher).
The following example contains a houseForSale
object with nested properties. We are using toHaveProperty
to check for the existence and values of various properties in the object. We are using toHaveProperty
to check for the existence and values of various properties in the object.
// Object containing house features to be tested
const houseForSale = {
bath: true,
bedrooms: 4,
kitchen: {
amenities: ['oven', 'stove', 'washer'],
area: 20,
wallColor: 'white',
'nice.oven': true,
},
livingroom: {
amenities: [
couch: [
['large', {dimensions: [20, 20]}],
['small', {dimensions: [10, 10]}],
],
},
],
},
'ceiling.height': 2,
};
test('this house has my desired features', () => {
// Example Referencing
expect(houseForSale).toHaveProperty('bath');
expect(houseForSale).toHaveProperty('bedrooms', 4);
expect(houseForSale).not.toHaveProperty('pool');
// Deep referencing using dot notation
expect(houseForSale).toHaveProperty('kitchen.area', 20);
expect(houseForSale).toHaveProperty('kitchen.amenities', [
'oven',
'stove',
'washer',
]);
expect(houseForSale).not.toHaveProperty('kitchen.open');
// Deep referencing using an array containing the keyPath
expect(houseForSale).toHaveProperty(['kitchen', 'area'], 20);
expect(houseForSale).toHaveProperty(
['kitchen', 'amenities'],
['oven', 'stove', 'washer'],
);
expect(houseForSale).toHaveProperty(['kitchen', 'amenities', 0], 'oven');
expect(houseForSale).toHaveProperty(
'livingroom.amenities[0].couch[0][1].dimensions[0]',
20,
);
expect(houseForSale).toHaveProperty(['kitchen', 'nice.oven']);
expect(houseForSale).not.toHaveProperty(['kitchen', 'open']);
// Referencing keys with dot in the key itself
expect(houseForSale).toHaveProperty(['ceiling.height'], 'tall');
});
.toBeCloseTo(number, numDigits?)
Use toBeCloseTo
to compare floating point numbers for approximate equality.
The optional numDigits
argument limits the number of digits to check after the decimal point. The optional numDigits
argument limits the number of digits to check after the decimal point. For the default value 2
, the test criterion is Math.abs(expected - received) < 0.005
(that is, 10 ** -2 / 2
).
Intuitive equality comparisons often fail, because arithmetic on decimal (base 10) values often have rounding errors in limited precision binary (base 2) representation. For example, this test fails: For example, this test fails:
test('adding works sanely with decimals', () => {
expect(0.2 + 0.1).toBe(0.3); // Fails!
});
});
It fails because in JavaScript, 0.2 + 0.1
is actually 0.30000000000000004
.
For example, this test passes with a precision of 5 digits:
test('adding works sanely with decimals', () => {
expect(0.2 + 0.1).toBeCloseTo(0.3, 5);
});
.toBeDefined()
Use .toBeDefined
to check that a variable is not undefined. Use .toBeDefined
to check that a variable is not undefined. For example, if you want to check that a function fetchNewFlavorIdea()
returns something, you can write:
test('there is a new flavor idea', () => {
expect(fetchNewFlavorIdea()).toBeDefined();
});
You could write expect(fetchNewFlavorIdea()).not.toBe(undefined)
, but it’s better practice to avoid referring to undefined
directly in your code.
.toBeFalsy()
Use .toBeFalsy
when you don’t care what a value is and you want to ensure a value is false in a boolean context. For example, let’s say you have some application code that looks like: For example, let’s say you have some application code that looks like:
drinkSomeLaCroix();
if (!getErrors()) {
drinkMoreLaCroix();
}
You may not care what getErrors
returns, specifically - it might return false
, null
, or 0
, and your code would still work. So if you want to test there are no errors after drinking some La Croix, you could write: So if you want to test there are no errors after drinking some La Croix, you could write:
test('drinking La Croix does not lead to errors', () => {
drinkSomeLaCroix();
expect(getErrors()).toBeFalsy();
});
In JavaScript, there are six falsy values: false
, 0
, ''
, null
, undefined
, and NaN
. Everything else is truthy. Everything else is truthy.
.toBeGreaterThan(number | bigint)
Use toBeGreaterThan
to compare received > expected
for number or big integer values. Use toBeGreaterThan
to compare received > expected
for number or big integer values. For example, test that ouncesPerCan()
returns a value of more than 10 ounces:
Use toBeGreaterThanOrEqual
to compare received >= expected
for number or big integer values. For example, test that ouncesPerCan()
returns a value of at least 12 ounces: For example, test that ouncesPerCan()
returns a value of at least 12 ounces:
test('ounces per can is at least 12', () => {
expect(ouncesPerCan()).toBeGreaterThanOrEqual(12);
});
.toBeLessThan(number | bigint)
Use toBeLessThan
to compare received < expected
for number or big integer values. Use toBeLessThan
to compare received < expected
for number or big integer values. For example, test that ouncesPerCan()
returns a value of less than 20 ounces:
test('ounces per can is less than 20', () => {
expect(ouncesPerCan()).toBeLessThan(20);
});
.toBeLessThanOrEqual(number | bigint)
Use toBeLessThanOrEqual
to compare received <= expected
for number or big integer values. For example, test that ouncesPerCan()
returns a value of at most 12 ounces: For example, test that ouncesPerCan()
returns a value of at most 12 ounces:
test('ounces per can is at most 12', () => {
expect(ouncesPerCan()).toBeLessThanOrEqual(12);
});
.toBeInstanceOf(Class)
Use .toBeInstanceOf(Class)
to check that an object is an instance of a class. This matcher uses instanceof
underneath. This matcher uses instanceof
underneath.
class A {}
expect(new A()).toBeInstanceOf(A);
expect(() => {}).toBeInstanceOf(Function);
expect(new A()).toBeInstanceOf(Function); // throws
.toBeNull()
.toBeNull()
is the same as .toBe(null)
but the error messages are a bit nicer. So use .toBeNull()
when you want to check that something is null. So use .toBeNull()
when you want to check that something is null.
function bloop() {
return null;
}
test('bloop returns null', () => {
expect(bloop()).toBeNull();
});
.toBeTruthy()
Use .toBeTruthy
when you don’t care what a value is and you want to ensure a value is true in a boolean context. For example, let’s say you have some application code that looks like: For example, let’s say you have some application code that looks like:
drinkSomeLaCroix();
if (thirstInfo()) {
drinkMoreLaCroix();
}
You may not care what thirstInfo
returns, specifically - it might return true
or a complex object, and your code would still work. So if you want to test that thirstInfo
will be truthy after drinking some La Croix, you could write: So if you want to test that thirstInfo
will be truthy after drinking some La Croix, you could write:
test('drinking La Croix leads to having thirst info', () => {
drinkSomeLaCroix();
expect(thirstInfo()).toBeTruthy();
});
In JavaScript, there are six falsy values: false
, 0
, ''
, null
, undefined
, and NaN
. Everything else is truthy. Everything else is truthy.
.toBeUndefined()
Use .toBeUndefined
to check that a variable is undefined. Use .toBeUndefined
to check that a variable is undefined. For example, if you want to check that a function bestDrinkForFlavor(flavor)
returns undefined
for the 'octopus'
flavor, because there is no good octopus-flavored drink:
test('the best drink for octopus flavor is undefined', () => {
expect(bestDrinkForFlavor('octopus')).toBeUndefined();
});
You could write expect(bestDrinkForFlavor('octopus')).toBe(undefined)
, but it’s better practice to avoid referring to undefined
directly in your code.
.toBeNaN()
Use .toBeNaN
when checking a value is NaN
.
test('passes when value is NaN', () => {
expect(NaN).toBeNaN();
expect(1).not.toBeNaN();
});
.toContain(item)
Use .toContain
when you want to check that an item is in an array. For testing the items in the array, this uses ===
, a strict equality check. .toContain
can also check whether a string is a substring of another string. For testing the items in the array, this uses ===
, a strict equality check. .toContain
can also check whether a string is a substring of another string.
For example, if getAllFlavors()
returns an array of flavors and you want to be sure that lime
is in there, you can write:
test('the flavor list contains lime', () => {
expect(getAllFlavors()).toContain('lime');
});
This matcher also accepts others iterables such as strings, sets, node lists and HTML collections.
.toContainEqual(item)
Use .toContainEqual
when you want to check that an item with a specific structure and values is contained in an array. For testing the items in the array, this matcher recursively checks the equality of all fields, rather than checking for object identity. For testing the items in the array, this matcher recursively checks the equality of all fields, rather than checking for object identity.
describe('my beverage', () => {
test('is delicious and not sour', () => {
const myBeverage = {delicious: true, sour: false};
expect(myBeverages()).toContainEqual(myBeverage);
});
});
.toEqual(value)
Use .toEqual
to compare recursively all properties of object instances (also known as “deep” equality). It calls Object.is
to compare primitive values, which is even better for testing than ===
strict equality operator. Use .toBe
to compare primitive values or to check referential identity of object instances. It calls Object.is
to compare values, which is even better for testing than ===
strict equality operator.
For example, .toEqual
and .toBe
behave differently in this test suite, so all the tests pass:
const can1 = {
flavor: 'grapefruit',
ounces: 12,
};
const can2 = {
flavor: 'grapefruit',
ounces: 12,
};
describe('the La Croix cans on my desk', () => {
test('have all the same properties', () => {
expect(can1).toEqual(can2);
});
test('are not the exact same can', () => {
expect(can1).not.toBe(can2);
});
});
tip
.toEqual
won’t perform a deep equality check for two errors. Only the message
property of an Error is considered for equality. It is recommended to use the .toThrow
matcher for testing against errors.
If differences between properties do not help you to understand why a test fails, especially if the report is large, then you might move the comparison into the expect
function. For example, use equals
method of Buffer
class to assert whether or not buffers contain the same content: For example, use equals
method of Buffer
class to assert whether or not buffers contain the same content:
- 使用
expect(received.equals(expected)).toBe(true)
代替expect(received).toEqual(expected)
- 使用
expect(received.equals(expected)).toBe(false)
代替expect(received).not.toEqual(expected)
.toMatch(regexp | string)
Use .toMatch
to check that a string matches a regular expression.
For example, you might not know what exactly essayOnTheBestFlavor()
returns, but you know it’s a really long string, and the substring grapefruit
should be in there somewhere. You can test this with: You can test this with:
describe('an essay on the best flavor', () => {
test('mentions grapefruit', () => {
expect(essayOnTheBestFlavor()).toMatch(/grapefruit/);
expect(essayOnTheBestFlavor()).toMatch(new RegExp('grapefruit'));
});
});
This matcher also accepts a string, which it will try to match:
describe('grapefruits are healthy', () => {
test('grapefruits are a fruit', () => {
expect('grapefruits').toMatch('fruit');
});
});
.toMatchObject(object)
Use .toMatchObject
to check that a JavaScript object matches a subset of the properties of an object. It will match received objects with properties that are not in the expected object. It will match received objects with properties that are not in the expected object.
You can also pass an array of objects, in which case the method will return true only if each object in the received array matches (in the toMatchObject
sense described above) the corresponding object in the expected array. This is useful if you want to check that two arrays match in their number of elements, as opposed to arrayContaining
, which allows for extra elements in the received array. This is useful if you want to check that two arrays match in their number of elements, as opposed to arrayContaining
, which allows for extra elements in the received array.
You can match properties against values or against matchers.
const houseForSale = {
bath: true,
bedrooms: 4,
kitchen: {
amenities: ['oven', 'stove', 'washer'],
area: 20,
wallColor: 'white',
},
};
const desiredHouse = {
bath: true,
kitchen: {
amenities: ['oven', 'stove', 'washer'],
wallColor: expect.stringMatching(/white|yellow/),
},
};
test('the house has my desired features', () => {
expect(houseForSale).toMatchObject(desiredHouse);
});
describe('toMatchObject applied to arrays', () => {
test('the number of elements must match exactly', () => {
expect([{foo: 'bar'}, {baz: 1}]).toMatchObject([{foo: 'bar'}, {baz: 1}]);
});
test('.toMatchObject is called for each elements, so extra object properties are okay', () => {
expect([{foo: 'bar'}, {baz: 1, extra: 'quux'}]).toMatchObject([
{foo: 'bar'},
{baz: 1},
]);
});
});
.toMatchSnapshot(propertyMatchers?, hint?)
This ensures that a value matches the most recent snapshot. This ensures that a value matches the most recent snapshot. Check out the Snapshot Testing guide for more information.
You can provide an optional propertyMatchers
object argument, which has asymmetric matchers as values of a subset of expected properties, if the received value will be an object instance. It is like toMatchObject
with flexible criteria for a subset of properties, followed by a snapshot test as exact criteria for the rest of the properties. It is like toMatchObject
with flexible criteria for a subset of properties, followed by a snapshot test as exact criteria for the rest of the properties.
You can provide an optional hint
string argument that is appended to the test name. You can provide an optional hint
string argument that is appended to the test name. Although Jest always appends a number at the end of a snapshot name, short descriptive hints might be more useful than numbers to differentiate multiple snapshots in a single it
or test
block. Jest sorts snapshots by name in the corresponding .snap
file. Jest sorts snapshots by name in the corresponding .snap
file.
.toMatchInlineSnapshot(propertyMatchers?, inlineSnapshot)
Ensures that a value matches the most recent snapshot.
You can provide an optional propertyMatchers
object argument, which has asymmetric matchers as values of a subset of expected properties, if the received value will be an object instance. It is like toMatchObject
with flexible criteria for a subset of properties, followed by a snapshot test as exact criteria for the rest of the properties. It is like toMatchObject
with flexible criteria for a subset of properties, followed by a snapshot test as exact criteria for the rest of the properties.
Jest adds the inlineSnapshot
string argument to the matcher in the test file (instead of an external .snap
file) the first time that the test runs.
Check out the section on Inline Snapshots for more info.
.toStrictEqual(value)
Use .toStrictEqual
to test that objects have the same types as well as structure.
Differences from .toEqual
:
- 值为
undefined
的属性会被比较。 比如, 当你使用.toStrictEqual
时,{a: undefined, b: 2}
和{b: 2}
的匹配结果为false - 稀疏数组会被比较。 比如,当你使用
.toStrictEqual
时,[, 1]
和[undefined, 1]
的匹配结果为false。 - 对象类型会被比较。 比如,包含相同属性、相同值的类实例与字面对象匹配结果为false。
class LaCroix {
constructor(flavor) {
this.flavor = flavor;
}
}
describe('the La Croix cans on my desk', () => {
test('are not semantically the same', () => {
expect(new LaCroix('lemon')).toEqual({flavor: 'lemon'});
expect(new LaCroix('lemon')).not.toStrictEqual({flavor: 'lemon'});
});
});
.toThrow(error?)
Also under the alias: .toThrowError(error?)
Use .toThrow
to test that a function throws when it is called. Use .toThrow
to test that a function throws when it is called. For example, if we want to test that drinkFlavor('octopus')
throws, because octopus flavor is too disgusting to drink, we could write:
test('throws on octopus', () => {
expect(() => {
drinkFlavor('octopus');
}).toThrow();
});
tip
Tips:你必须使用外层函数包装测试代码,否则无法捕获错误且断言会失败。
You can provide an optional argument to test that a specific error is thrown:
- 正则表达式:错误消息匹配传入的表达式
- 字符串:错误消息包含传入的字符串
- 错误对象:错误消息等于传入对象的
message
属性 - 错误类:错误对象是传入错误类的实例
For example, let’s say that drinkFlavor
is coded like this:
function drinkFlavor(flavor) {
if (flavor == 'octopus') {
throw new DisgustingFlavorError('yuck, octopus flavor');
}
// Do some other stuff
}
We could test this error gets thrown in several ways:
test('throws on octopus', () => {
function drinkOctopus() {
drinkFlavor('octopus');
}
// Test that the error message says "yuck" somewhere: these are equivalent
expect(drinkOctopus).toThrowError(/yuck/);
expect(drinkOctopus).toThrowError('yuck');
// Test the exact error message
expect(drinkOctopus).toThrowError(/^yuck, octopus flavor$/);
expect(drinkOctopus).toThrowError(new Error('yuck, octopus flavor'));
// Test that we get a DisgustingFlavorError
expect(drinkOctopus).toThrowError(DisgustingFlavorError);
});
.toThrowErrorMatchingSnapshot(hint?)
Use .toThrowErrorMatchingSnapshot
to test that a function throws an error matching the most recent snapshot when it is called.
You can provide an optional hint
string argument that is appended to the test name. You can provide an optional hint
string argument that is appended to the test name. Although Jest always appends a number at the end of a snapshot name, short descriptive hints might be more useful than numbers to differentiate multiple snapshots in a single it
or test
block. Jest sorts snapshots by name in the corresponding .snap
file. Jest sorts snapshots by name in the corresponding .snap
file.
For example, let’s say you have a drinkFlavor
function that throws whenever the flavor is 'octopus'
, and is coded like this:
function drinkFlavor(flavor) {
if (flavor == 'octopus') {
throw new DisgustingFlavorError('yuck, octopus flavor');
}
// Do some other stuff
}
The test for this function will look this way:
test('throws on octopus', () => {
function drinkOctopus() {
drinkFlavor('octopus');
}
expect(drinkOctopus).toThrowErrorMatchingSnapshot();
});
And it will generate the following snapshot:
Check out React Tree Snapshot Testing for more information on snapshot testing.
Use .toThrowErrorMatchingInlineSnapshot
to test that a function throws an error matching the most recent snapshot when it is called.
Jest adds the inlineSnapshot
string argument to the matcher in the test file (instead of an external file) the first time that the test runs.