Skip to main content
Version: 29.7

Expect

Cuando estás escribiendo tests, a menudo necesitas comprobar que los valores cumplen ciertas condiciones. expect te da acceso a un número de marcadores que te permiten validar diferentes cosas.

tip

For additional Jest matchers maintained by the Jest Community check out jest-extended.

info

Los ejemplos de TypeScript de esta página sólo funcionarán como documentados si se importan explícitamente APIs de Jest:

import {expect, jest, test} from '@jest/globals';

Consult the Getting Started guide for details on how to setup Jest with TypeScript.

Referencia​

Expect​

expect(value)​

La función expect se utiliza cada vez que desea testear un valor. Rara vez se utiliza expect por sí mismo. En su lugar, utilizarás expect junto a una función de "comparación" para afirmar algo sobre un valor.

Es más fácil entenderlo con este ejemplo. Digamos que tenemos un método mejorSabor() que se supone que devuelve el texto 'grapefruit'. Así es cómo sería el test:

test('el mejor sabor es de melocotón', () => {
  expect(mejorSabor()).toBe('melocotón');
});

En este caso, toBe es la función de comparación. Hay una gran cantidad de funciones matcher diferentes, documentadas a continuación, para ayudarte a probar cosas diferentes.

El argumento expect debe ser el valor que produce tu código, y cualquier argumento de comparación debe ser el valor correcto. Si los mezclas, tus test problablemente seguiran funcionando, pero los mensajes de error seran confusos.

Modifiers​

.not​

Si sabes cómo testear algo, .no te permite comprobar su opuesto. Por ejemplo, este código testea que el mejor sabor de La Croix no es coco:

import serializer from 'my-serializer-module';
expect.addSnapshotSerializer(serializer);

// afecta a las afirmaciones expect(value).toMatchSnapshot() en el archivo de test

.resolves​

Utiliza resolves para desenvolver el valor de una promesa cumplida, para que así cualquier otro marcados pueda ser encadenado. Si la promesa se rechaza la afirmación falla.

Por ejemplo, este código testea que la promesa resuelve y que el valor resultando es 'limon':

test('el mejor sabor no es coco', () => {
  expect(mejorSaborLaCroix()).not.toBe('coco');
});
note

Since you are still testing promises, the test is still asynchronous. Hence, you will need to tell Jest to wait by returning the unwrapped assertion.

Alternativamente, se puede usar async/await en combinación con .resolves:

test('resuelve a limon', () => {
  // Es esencial que se agregue un statement de return
  return expect(Promise.resolve('limon')).resolves.toBe('limon');
});

.rejects​

Usa .rejects para desenvolver el valor de una promesa cumplida, para que así cualquier otro marcados pueda ser encadenado. Si la promesa es rechazada la afirmación falla.

Por ejemplo, este código prueba que la promesa rechaza con la razón 'octopus':

test('rejects to octopus', () => {
  // make sure to add a return statement
  return expect(Promise.reject(new Error('octopus'))).rejects.toThrow(
    'octopus',
  );
});
note

Since you are still testing promises, the test is still asynchronous. Hence, you will need to tell Jest to wait by returning the unwrapped assertion.

Alternativamente, puede utilizar async/await combinado con .rejects.

test('rejects to octopus', async () => {
  await expect(Promise.reject(new Error('octopus'))).rejects.toThrow('octopus');
});

Matchers​

.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.

Por ejemplo, el código a continuación valida algunas propiedades del objeto lata:

const lata = {
  nombre: 'pomelo',
  onzas : 12,
};

describe('la lata', () => {
  test('tiene 12 onzas', () => {
    expect(lata.onzas).toBe(12);
  });

  test('tiene un nombre sofisticado', () => {
    expect(lata.nombre).toBe('pomelo');
  });
});

Don't use .toBe with floating-point numbers. Por ejemplo, debido al redondeo, en JavaScript 0,2 + 0,1 no es estrictamente igual a 0,3. Si tienes números de punto flotante, prueba .toBeCloseTo en su lugar.

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:

  • rewrite expect(received).toBe(expected) as expect(Object.is(received, expected)).toBe(true)
  • rewrite expect(received).not.toBe(expected) as expect(Object.is(received, expected)).toBe(false)

.toHaveBeenCalled()​

También bajo el alias: .toBeCalled()

Use .toHaveBeenCalled to ensure that a mock function was called.

Por ejemplo, digamos que tienes una función beberCada(beber, Array<sabor>) que toma una función beber y la aplica a un arreglo de bebidas. You might want to check that drink gets called. Puedes hacerlo con esta serie de tests:

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)

Usa .toHaveBeenCalledTimes para asegurar que una función "mock" se llamo un número de veces exacto.

For example, let's say you have a drinkAll(drink, flavour) function that takes a drink function and applies it to all available beverages. Puede que quieras comprobar que la función beber se llamó un numero exacto de veces. Puedes hacerlo con esta serie de tests:

test('aplicarATodosLosSabores deja el mango para el final', () => {
  const bebida = jest.fn();
  aplicarATodosLosSabores(bebida);
  expect(bebida).toHaveBeenLastCalledWith('mango');
});

.toHaveBeenCalledWith(arg1, arg2, ...)​

También bajo el alias: .toBeCalledWith()

Usa .toHaveBeenCalledWith para asegurar que una función mock haya sido llamada con argumentos específicos. The arguments are checked with the same algorithm that .toEqual uses.

Por ejemplo, digamos que tienes una bebida con una función registrar, y aplicarATodo(f) que aplica la función f a todas las bebidas registradas. Para asegurarte que funciona, puedes escribir:

test('beberCada bebe cada bebida', () => {
  const beber = jest.fn();
  beberCada(beber, ['limon', 'pulpo']);
  expect(beber).toHaveBeenCalledTimes(2);
});

.toHaveBeenLastCalledWith(arg1, arg2, ...)​

También bajo el alias: .lastCalledWith(arg1, arg2, ...)

Si tienes una función mock, puedes usar .toHaveBeenLastCalledWith para ver los argumentos con los que fue llamada la ultima vez. Por ejemplo digamos que tienes una función aplicarATodosLosSabores(f) que aplica la función f a diversos sabores, y quieres asegurarte que la ultima vez que se llama a esta función el último sabor al que se le aplica la función es 'mango'. Puedes escribir:

test('registro aplicado correctamente a La Croix naranja', () => {
  const bebida = new LaCroix('naranja');
  registrar(bebida);
  const f = jest.fn();
  aplicarATodo(f);
  expect(f).toHaveBeenCalledWith(bebida);
});

.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'. Puedes escribir:

test('drinkEach drinks each drink', () => {
  const drink = jest.fn();
  drinkEach(drink, ['lemon', 'octopus']);
  expect(drink).toHaveBeenNthCalledWith(1, 'lemon');
  expect(drink).toHaveBeenNthCalledWith(2, 'octopus');
});
note

The nth argument must be positive integer starting from 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. Puedes escribir:

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.

For example, let's say you have a mock drink that returns true. Puedes escribir:

test('drink returns twice', () => {
  const drink = jest.fn(() => true);

  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. Puedes escribir:

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. 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. Puedes escribir:

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. 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. Puedes escribir:

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

The nth argument must be positive integer starting from 1.

.toHaveLength(number)​

Utilice .toHaveLength para verificar que un objeto tenga longitud de .length y tenga cierto valor numérico.

Es especialmente útil para verificar el tamaño de cadenas o arreglos.

expect([1, 2, 3]).toHaveLength(3);
expect('abc').toHaveLength(3);
expect('').not.toHaveLength(5);

.toHaveProperty(pathLlave, valor?)​

Utilice .toHaveProperty para verificar si la propiedad en la referencia de pathLlave existe para un objeto dado. For checking deeply nested properties in an object you may use dot notation 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).

El siguiente ejemplo contiene un objeto casaEnVenta con propiedades anidadas. 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(número, númeroDigitos?)​

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. 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:

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);
});

Because floating point errors are the problem that toBeCloseTo solves, it does not support big integer values.

.toBeDefined()​

Usa .toBeDefined para verificar que una variable no sea undefined. For example, if you want to check that a function fetchNewFlavorIdea() returns something, you can write:

test('la mejor bebida con sabor a pulpo es undefined', () => {
  expect(mejorBebidaPorSabor('pulpo')).toBeUndefined();
});

Puedes escribir expect(conseguirNuevaIdeaSabor()).not.toBe(undefined), pero es buena practica omitir el uso de undefined directamente en el código.

.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:

test('hay una nueva idea de sabor', () => {
  expect(conseguirNuevaIdeaSabor()).toBeDefined();
});

Puede que no te importe el valor que conseguirErrores regrese, específicamente - podría regresar false, null, o 0, y el código funcionaría correctamente. Si quieres probar que no hay errores después de tomar algo de La Croix, podrías escribir:

beberPocoLaCroix();
if (!conseguirErrores()) {
  beberMasLaCroix();
}

En JavaScript, hay seis valores falsos en contexto booleano, o "falsy": false, 0, '', null, undefined, y NaN. Cualquier otro valor es verdadero en contexto booleano, o "truthy".

.toBeGreaterThan(number | bigint)​

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:

test('beber LaCroix no provoca errores', () => {
  beberPocoLaCroix();
  expect(conseguirErrores()).toBeFalsy();
});

.toBeGreaterThanOrEqual(number | bigint)​

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:

test('onzas por lata es mayor a 10', () => {
  expect(onzasPorLata()).toBeGreaterThan(10);
});

.toBeLessThan(number | bigint)​

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('onzas por lata es por lo menos 12', () => {
  expect(onzasPorLata()).toBeGreaterThanOrEqual(12);
});

.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:

test('onzas por lata es menor a 20', () => {
  expect(onzasPorLata()).toBeLessThan(20);
});

.toBeInstanceOf(Class)​

Utiliza .toBeInstanceOf(Class) para verificar que un objeto es instancia de cierta clase. Esta comparación se realiza de manera interna ocupando instanceof.

test('onzas por lata es a lo mucho 12', () => {
  expect(onzasPorLata()).toBeLessThanOrEqual(12);
});

.toBeNull()​

.toBeNull() es idéntico a .toBe(null) pero con mensajes de error más claros. Por tanto, es preferible usar .toBeNull() para verificar si algo es nulo.

class A {}

expect(new A()).toBeInstanceOf(A);
expect(() => {}).toBeInstanceOf(Function);
expect(new A()).toBeInstanceOf(Function); // avienta error

.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:

function bloop() {
  return null;
}

test('bloop regresa null', () => {
  expect(bloop()).toBeNull();
});

Puede que no te importe el valor que infoSed regrese, específicamente - podría regresar trueo un objeto complejo, y el código funcionaría correctamente. So if you want to test that thirstInfo will be truthy after drinking some La Croix, you could write:

beberPocoLaCroix();
if (infoSed()) {
  beberMasLaCroix();
}

En JavaScript, hay seis valores falsos en contexto booleano, o "falsy": false, 0, '', null, undefined, y NaN. Cualquier otro valor es verdadero en contexto booleano, o "truthy".

.toBeUndefined()​

Usa .toBeDefined para verificar que una variable es undefined. Por ejemplo, si quieres verificar que la función mejorBebidaPorSabor(sabor) regresa undefined para el sabor 'pulpo', porque no existe ninguna bebida con sabor a pulpo que sepa bien:

test('beber La Croix lleva a conseguir info de sed', () => {
  beberPocoLaCroix();
  expect(infoSed()).toBeTruthy();
});

Podría escribir expect(mejorBebidaPorSabor('pulpo')).toBe(undefined), pero es buena practica omitir el uso de undefined directamente en el código.

.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 example, if getAllFlavors() returns an array of flavors and you want to be sure that lime is in there, you can write:

test('la lista de sabores contiene lima', () => {
  expect(conseguirTodosSabores()).toContain('lima');
});

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.

test('la lista de sabores contiene lima', () => {
  expect(conseguirTodosSabores()).toContain('lima');
});

.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.

For example, .toEqual and .toBe behave differently in this test suite, so all the tests pass:

describe('mi bebida', () => {
  test('es deliciosa y no es agría', () => {
    const miBebida = {deliciosa: true, agria: false};
    expect(misBebidas()).toContainEqual(miBebida);
  });
});
tip

toEqual ignores object keys with undefined properties, undefined array items, array sparseness, or object type mismatch. To take these into account use .toStrictEqual instead.

info

.toEqual won't perform a deep equality check for two errors. Sólo la propiedad message de un error se verifica para comparar igualdad. Se recomienda utilizar el método .toThrow para probar errores.

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:

  • rewrite expect(received).toEqual(expected) as expect(received.equals(expected)).toBe(true)
  • rewrite expect(received).not.toEqual(expected) as expect(received.equals(expected)).toBe(false)

.toMatch(regexp | string)​

Utilice .toMatch para verificar que la cadena coincida con una expresión regular (Regex).

Por ejemplo, puede que no sepas el valor exacto que ensayoSobreElMejorSabor() regresa, pero sabes que es una cadena muy larga, y que la cadena toronja es parte del contenido. Podemos probarlo con:

const lata1 = {
  sabor: 'toronja',
  onzas: 12,
};
const lata2 = {
  sabor: 'toronja',
  onzas: 12,
};

describe('las latas de La Croix en mi escritorio', () => {
  test('tienen las mismas propiedades', () => {
    expect(lata1).toEqual(lata2);
  });
  test('no son la misma lata', () => {
    expect(lata1).not.toBe(lata2);
  });
});

Este método acepta también una cadena, con la que va a intentar coincidir:

describe('un ensayo sobre el mejor sabor', () => {
  test('menciona toronja', () => {
    expect(ensayoSobreElMejorSabor()).toMatch(/toronja/);
    expect(ensayoSobreElMejorSabor()).toMatch(new RegExp('toronja'));
  });
});

.toMatchObject(object)​

Usa .toMatchObject para comprobar que un objeto de JavaScript coincide con un subconjunto de las propiedades de un objeto. Hará match de objetos recibidos cuyas propiedades no están en el objeto esperado.

También se puede pasar un arreglo de objetos, en cuyo caso el método regresara true solo si cada objeto en el arreglo hace match (como descrito en toMatchObject anteriormente) con el objeto correspondiente en el arreglo esperado. Esto es útil si se desea verificar que dos arreglos coinciden en el número de sus elementos, opuesto a arrayContaining, lo cual permite que el arreglo recibido contenga elementos adicionales.

Se puede hacer match de propiedades a través de sus valores o con matchers.

describe('las toronjas son saludables', () => {
  test('las toronjas son frutas', () => {
    expect('toronjas').toMatch('fruta');
  });
});
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?)​

Esto garantiza que un valor coincide con el snapshot más reciente. Véase la guia de Snapshot Testing para más información.

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.

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.

.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.

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 structure and type.

Differences from .toEqual:

  • keys with undefined properties are checked, e.g. {a: undefined, b: 2} will not equal {b: 2};
  • undefined items are taken into account, e.g. [2] will not equal [2, undefined];
  • array sparseness is checked, e.g. [, 1] will not equal [undefined, 1];
  • object types are checked, e.g. a class instance with fields a and b will not equal a literal object with fields a and b.
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?)

Utilice .toThrow en una prueba para verificar que una función arroja un error cuando se llama. Por ejemplo, si deseamos probar que beberSabor('pulpo') arroja un error, porque el sabor a pulpo es demasiado repugnante para beber, podemos escribir:

test('arroja error en pulpo', () => {
  function beberPulpo() {
    beberSabor('pulpo');
  }

  expect(beberPulpo).toThrowErrorMatchingSnapshot();
});
tip

You must wrap the code in a function, otherwise the error will not be caught and the assertion will fail.

You can provide an optional argument to test that a specific error is thrown:

  • regular expression: error message matches the pattern
  • string: error message includes the substring
  • error object: error message is equal to the message property of the object
  • error class: error object is instance of class

Por ejemplo, digamos que el código de beberSabor es el siguiente:

function drinkFlavor(flavor) {
  if (flavor === 'octopus') {
    throw new DisgustingFlavorError('yuck, octopus flavor');
  }
  // Do some other stuff
}

Podríamos probar que este error lanza una excepción de varias formas:

test('throws on octopus', () => {
  function drinkOctopus() {
    drinkFlavor('octopus');
  }

  // Test that the error message says "yuck" somewhere: these are equivalent
  expect(drinkOctopus).toThrow(/yuck/);
  expect(drinkOctopus).toThrow('yuck');

  // Test the exact error message
  expect(drinkOctopus).toThrow(/^yuck, octopus flavor$/);
  expect(drinkOctopus).toThrow(new Error('yuck, octopus flavor'));

  // Test that we get a DisgustingFlavorError
  expect(drinkOctopus).toThrow(DisgustingFlavorError);
});

.toThrowErrorMatchingSnapshot(hint?)​

Utilice .toThrowErrorMatchingSnapshot para probar que una función arroja un error igual al snapshot más reciente cuando es llamada.

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.

Por ejemplo, digamos que tienes una función beberSabor que arroja un error cuando el sabor es 'pulpo', y su código es el siguiente:

function drinkFlavor(flavor) {
  if (flavor === 'octopus') {
    throw new DisgustingFlavorError('yuck, octopus flavor');
  }
  // Do some other stuff
}

El test para esta función se verá así:

function beberSabor(sabor) {
  if (sabor == 'pulpo') {
    throw new ErrorSaborRepugnante('guac! sabor a pulpo');
  }
  // Funcionalidad extra
}

Y generará el siguiente snapshot:

exports[`drinking flavors throws on octopus 1`] = `"yuck, octopus flavor"`;

Check out React Tree Snapshot Testing for more information on snapshot testing.

.toThrowErrorMatchingInlineSnapshot(inlineSnapshot)​

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 .snap file) the first time that the test runs.

Check out the section on Inline Snapshots for more info.

Asymmetric Matchers​

expect.anything()​

expect.anything() aprobará cualquier cosa excepto null o undefined. You can use it inside toEqual or toHaveBeenCalledWith instead of a literal value. Por ejemplo, si quieres asegurarte de que un mock ha sido llamado con un argumento que no sea null:

test('map calls its argument with a non-null argument', () => {
  const mock = jest.fn();
  [1].map(x => mock(x));
  expect(mock).toHaveBeenCalledWith(expect.anything());
});

expect.any(constructor)​

expect.any(constructor) matches anything that was created with the given constructor or if it's a primitive that is of the passed type. You can use it inside toEqual or toHaveBeenCalledWith instead of a literal value. Por ejemplo, si quieres asegurarte de que un mock ha sido llamado con un número:

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).toHaveBeenCalledWith(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).toHaveBeenCalledWith(expect.any(Number));
});

expect.arrayContaining(array)​

expect.arrayContaining(array) aprueba que la matriz recibida contiene todos los elementos de la matriz esperada. Eso significa que la matriz esperada es un subconjunto de la matriz recibida. Por tanto, aprueba una matriz recibida que contenga elementos que no estén en la matriz esperada.

Puedes utilizarla en vez de usar un valor literal:

  • in toEqual or toHaveBeenCalledWith
  • to match a property in objectContaining or toMatchObject
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! 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.arrayContaining(expected),
    );
  });
});

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.

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.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.objectContaining(object)​

expect.objectContaining(object) compara recursivamente con cualquier objeto recibido que cumpla con las propiedades esperadas. Es decir, el objeto esperado es un subconjunto del objeto recibido. Therefore, it matches a received object which contains properties that are present in the expected object.

En lugar de verificar los valores de propiedades en el objeto esperado, se pueden ocupar matchers, como expect.anything(), entre otros.

Por ejemplo, si se espera que la función onPress sea llamada con el objeto Event, y solo se necesita verificar que el evento tiene las propiedades event.x y event.y. Puedes hacer esto con:

test('onPress gets called with the right thing', () => {
  const onPress = jest.fn();
  simulatePresses(onPress);
  expect(onPress).toHaveBeenCalledWith(
    expect.objectContaining({
      x: expect.any(Number),
      y: expect.any(Number),
    }),
  );
});

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. De tal manera que, hace match con un objeto que contiene propiedades que no se encuentran en el objeto esperado.

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.stringContaining(string)​

expect.stringContaining(string) matches the received value if it is a string that contains the exact expected string.

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.stringMatching(string | regexp)​

expect.stringMatching(string | regexp) matches the received value if it is a string that matches the expected string or regular expression.

Puedes utilizarla en vez de usar un valor literal:

  • in toEqual or toHaveBeenCalledWith
  • to match an element in arrayContaining
  • to match a property in objectContaining or toMatchObject

Este ejemplo también muestra cómo se pueden anidar múltiples marcadores de comparación asimétricas, con expect.stringMatching dentro de 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.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));
  });
});

Assertion Count​

expect.assertions(number)​

expect.assertions(number) verifica que un cierto número de afirmaciones han sido realizadas durante un test. Esto es útil a la hora de probar código asíncrono para asegurarnos de que las afirmaciones de un callback fueron llamadas.

Por ejemplo, supongamos que tenemos una función doAsync que recibe dos devoluciones de llamada callback1 y callback2, asincrónicamente se llamará a ambas en un orden desconocido. Podemos comprobarlo con:

test('prepareState prepara un estado valido', () => {
  expect.hasAssertions();
  prepareState(state => {
    expect(validateState(estado)).toBeTruthy();
  });
  return waitOnState();
});

La llamada de expect.assertions(2) asegura que ambas devoluciones de llamada son efectivamente ejecutadas.

expect.hasAssertions()​

expect.hasAssertions() verifica que al menos una verificación es llamada durante un test. Esto es útil a la hora de probar código asíncrono para asegurarnos de que las afirmaciones de un callback fueron llamadas.

Por ejemplo, digamos que tenemos unas pocas funciones y todas tratan con un estado. prepareState llama a una devolución de llamada con un objeto de estado, validateState se ejecuta en este objeto de estado, y waitOnState devuelve una promesa que espera hasta que las devoluciones de llamada de prepareState completen. Podemos comprobarlo con:

test('doAsync llama a ambos callbacks', () => {
  expect.assertions(2);
  function callback1(data) {
    expect(data).toBeTruthy();
  }
  function callback2(data) {
    expect(data).toBeTruthy();
  }

  doAsync(callback1, callback2);
});

La llamada de expect.hasAssertions() asegura que ambas devoluciones de llamada de prepareState son efectivamente ejecutadas.

Extend Utilities​

expect.addEqualityTesters(testers)​

You can use expect.addEqualityTesters to add your own methods to test if two objects are equal. For example, let's say you have a class in your code that represents volume and can determine if two volumes using different units are equal. You may want toEqual (and other equality matchers) to use this custom equality method when comparing to Volume classes. You can add a custom equality tester to have toEqual detect and apply custom logic when comparing Volume classes:

Volume.js
// For simplicity in this example, we'll just support the units 'L' and 'mL'
export class Volume {
  constructor(amount, unit) {
    this.amount = amount;
    this.unit = unit;
  }

  toString() {
    return `[Volume ${this.amount}${this.unit}]`;
  }

  equals(other) {
    if (this.unit === other.unit) {
      return this.amount === other.amount;
    } else if (this.unit === 'L' && other.unit === 'mL') {
      return this.amount * 1000 === other.unit;
    } else {
      return this.amount === other.unit * 1000;
    }
  }
}
areVolumesEqual.js
import {expect} from '@jest/globals';
import {Volume} from './Volume.js';

function areVolumesEqual(a, b) {
  const isAVolume = a instanceof Volume;
  const isBVolume = b instanceof Volume;

  if (isAVolume && isBVolume) {
    return a.equals(b);
  } else if (isAVolume === isBVolume) {
    return undefined;
  } else {
    return false;
  }
}

expect.addEqualityTesters([areVolumesEqual]);
__tests__/Volume.test.js
import {expect, test} from '@jest/globals';
import {Volume} from '../Volume.js';
import '../areVolumesEqual.js';

test('are equal with different units', () => {
  expect(new Volume(1, 'L')).toEqual(new Volume(1000, 'mL'));
});

Custom equality testers API​

Custom testers are functions that return either the result (true or false) of comparing the equality of the two given arguments or undefined if the tester does not handle the given objects and wants to delegate equality to other testers (for example, the builtin equality testers).

Custom testers are called with 3 arguments: the two objects to compare and the array of custom testers (used for recursive testers, see the section below).

These helper functions and properties can be found on this inside a custom tester:

this.equals(a, b, customTesters?)​

Esta es una función de igualdad profunda que regresará true si dos objetos tienen los mismos valores (recursivamente). It optionally takes a list of custom equality testers to apply to the deep equality checks. If you use this function, pass through the custom testers your tester is given so further equality checks equals applies can also use custom testers the test author may have configured. See the example in the Recursive custom equality testers section for more details.

Matchers vs Testers​

Matchers are methods available on expect, for example expect().toEqual(). toEqual is a matcher. A tester is a method used by matchers that do equality checks to determine if objects are the same.

Custom matchers are good to use when you want to provide a custom assertion that test authors can use in their tests. For example, the toBeWithinRange example in the expect.extend section is a good example of a custom matcher. Sometimes a test author may want to assert two numbers are exactly equal and should use toBe. Other times, however, a test author may want to allow for some flexibility in their test, and toBeWithinRange may be a more appropriate assertion.

Custom equality testers are good for globally extending Jest matchers to apply custom equality logic for all equality comparisons. Test authors can't turn on custom testers for certain assertions and turn them off for others (a custom matcher should be used instead if that behavior is desired). For example, defining how to check if two Volume objects are equal for all matchers would be a good custom equality tester.

Recursive custom equality testers​

If your custom equality testers are testing objects with properties you'd like to do deep equality with, you should use the this.equals helper available to equality testers. This equals method is the same deep equals method Jest uses internally for all of its deep equality comparisons. It's the method that invokes your custom equality tester. It accepts an array of custom equality testers as a third argument. Custom equality testers are also given an array of custom testers as their third argument. Pass this argument into the third argument of equals so that any further equality checks deeper into your object can also take advantage of custom equality testers.

For example, let's say you have a Book class that contains an array of Author classes and both of these classes have custom testers. The Book custom tester would want to do a deep equality check on the array of Authors and pass in the custom testers given to it, so the Authors custom equality tester is applied:

customEqualityTesters.js
function areAuthorEqual(a, b) {
  const isAAuthor = a instanceof Author;
  const isBAuthor = b instanceof Author;

  if (isAAuthor && isBAuthor) {
    // Authors are equal if they have the same name
    return a.name === b.name;
  } else if (isAAuthor === isBAuthor) {
    return undefined;
  } else {
    return false;
  }
}

function areBooksEqual(a, b, customTesters) {
  const isABook = a instanceof Book;
  const isBBook = b instanceof Book;

  if (isABook && isBBook) {
    // Books are the same if they have the same name and author array. We need
    // to pass customTesters to equals here so the Author custom tester will be
    // used when comparing Authors
    return (
      a.name === b.name && this.equals(a.authors, b.authors, customTesters)
    );
  } else if (isABook === isBBook) {
    return undefined;
  } else {
    return false;
  }
}

expect.addEqualityTesters([areAuthorsEqual, areBooksEqual]);
note

Remember to define your equality testers as regular functions and not arrow functions in order to access the tester context helpers (e.g. this.equals).

expect.addSnapshotSerializer(serializer)​

Puedes llamar a expect.addSnapshotSerializer para agregar un módulo que formatee estructuras de datos específicas de la aplicación.

Para un archivo de test individual, un módulo añadido precede a los módulos de snapshotSerializers en la configuración, que preceden los serializadores de instantánea predeterminados para tipos de JavaScript integrados y elementos de React. El último módulo añadido, es el primero módulo testeado.

import serializer from 'my-serializer-module';
expect.addSnapshotSerializer(serializer);

// afecta a las afirmaciones expect(value).toMatchSnapshot() en el archivo de test

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 create-react-app.

Véase configurando Jest para más información.

expect.extend(matchers)​

Puedes utilizar expect.extend para añadir tus propios comparadores a Jest. For example, let's say that you're testing a number utility library and you're frequently asserting that numbers appear within particular ranges of other numbers. You could abstract that into a toBeWithinRange matcher:

toBeWithinRange.js
import {expect} from '@jest/globals';

function toBeWithinRange(actual, floor, ceiling) {
  if (
    typeof actual !== 'number' ||
    typeof floor !== 'number' ||
    typeof ceiling !== 'number'
  ) {
    throw new TypeError('These must be of type number!');
  }

  const pass = actual >= floor && actual <= ceiling;
  if (pass) {
    return {
      message: () =>
        `expected ${this.utils.printReceived(
          actual,
        )} not to be within range ${this.utils.printExpected(
          `${floor} - ${ceiling}`,
        )}`,
      pass: true,
    };
  } else {
    return {
      message: () =>
        `expected ${this.utils.printReceived(
          actual,
        )} to be within range ${this.utils.printExpected(
          `${floor} - ${ceiling}`,
        )}`,
      pass: false,
    };
  }
}

expect.extend({
  toBeWithinRange,
});
__tests__/ranges.test.js
import {expect, test} from '@jest/globals';
import '../toBeWithinRange';

test('is within range', () => expect(100).toBeWithinRange(90, 110));

test('is NOT within range', () => expect(101).not.toBeWithinRange(0, 100));

test('asymmetric ranges', () => {
  expect({apples: 6, bananas: 3}).toEqual({
    apples: expect.toBeWithinRange(1, 10),
    bananas: expect.not.toBeWithinRange(11, 20),
  });
});
toBeWithinRange.d.ts
// optionally add a type declaration, e.g. it enables autocompletion in IDEs
declare module 'expect' {
  interface AsymmetricMatchers {
    toBeWithinRange(floor: number, ceiling: number): void;
  }
  interface Matchers<R> {
    toBeWithinRange(floor: number, ceiling: number): R;
  }
}

export {};
tip

The type declaration of the matcher can live in a .d.ts file or in an imported .ts module (see JS and TS examples above respectively). If you keep the declaration in a .d.ts file, make sure that it is included in the program and that it is a valid module, i.e. it has at least an empty export {}.

tip

Instead of importing toBeWithinRange module to the test file, you can enable the matcher for all tests by moving the expect.extend call to a setupFilesAfterEnv script:

import {expect} from '@jest/globals';
// remember to export `toBeWithinRange` as well
import {toBeWithinRange} from './toBeWithinRange';

expect.extend({
  toBeWithinRange,
});

Async Matchers​

expect.extend also supports async matchers. Async matchers return a Promise so you will need to await the returned value. Let's use an example matcher to illustrate the usage of them. We are going to implement a matcher called toBeDivisibleByExternalValue, where the divisible number is going to be pulled from an external source.

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();
});

Custom Matchers API​

Matchers should return an object (or a Promise of an object) with two keys. pass indica si hubo un acierto o no, y message proporciona una función sin argumentos que devuelve un mensaje de error en caso de fallo. Así, cuando pass es falso, message debe devolver el mensaje de error para cuando expect(x).tuComparador(). Y cuando pass es 'true', message debe devolver el mensaje de error para cuando expect(x).not.tuComparador().

Matchers are called with the argument passed to expect(x) followed by the arguments passed to .yourMatcher(y, z):

expect.extend({
  yourMatcher(x, y, z) {
    return {
      pass: true,
      message: () => '',
    };
  },
});

These helper functions and properties can be found on this inside a custom matcher:

this.isNot​

A boolean to let you know this matcher was called with the negated .not modifier allowing you to display a clear and correct matcher hint (see example code).

this.promise​

A string allowing you to display a clear and correct matcher hint:

  • 'rejects' if matcher was called with the promise .rejects modifier
  • 'resolves' if matcher was called with the promise .resolves modifier
  • '' if matcher was not called with a promise modifier

this.equals(a, b, customTesters?)​

Esta es una función de igualdad profunda que regresará true si dos objetos tienen los mismos valores (recursivamente). It optionally takes a list of custom equality testers to apply to the deep equality checks (see this.customTesters below).

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 jest-matcher-utils.

Las más útiles son matcherHint, printExpected y printReceived para dar formato mas agradable a los mensajes de error. Por ejemplo, echa un vistazo en la implementación para el comparador toBe:

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};
  },
});

Esto mostrará algo así:

  expect(received).toBe(expected)

    Expected value to be (using Object.is):
      "banana"
    Received:
      "apple"

Cuando una afirmación falla, el mensaje de error debería dar las señales necesarias para que el usuario pueda resolver sus problemas rápidamente. Deberías crear mensajes de errores precisos para que los usuarios de tus afirmaciones personalizadas se sientan cómodos usándolas.

this.customTesters​

If your matcher does a deep equality check using this.equals, you may want to pass user-provided custom testers to this.equals. The custom equality testers the user has provided using the addEqualityTesters API are available on this property. The built-in Jest matchers pass this.customTesters (along with other built-in testers) to this.equals to do deep equality, and your custom matchers may want to do the same.

Custom snapshot matchers​

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.slice(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. 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.slice(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"`
  );
  */
});

async​

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');

expect.extend({
  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"`);
});