Al mirar los documentos y mi propia experimentación para confirmarlo, la diferencia está en el manejo de los objetos anidados dentro de los accesorios pasados como una expectativa.

Si el objeto esperado tiene una propiedad, que contiene un objeto, que contiene algunas pero no todas las propiedades de la propiedad equivalente del objeto real, entonces:

• .toMatchObject() todavía pasará, como se ve en los documentos .

• expect.objectContaining() fallará (a menos que declare esa propiedad en el propio objeto de expectativa con expect.objectContaining() )

Ejemplos (probados en Jest):

 // objectContaining, with nested object, containing full props/values // PASSES expect({ position: { x: 0, y: 0 } }).toEqual(expect.objectContaining({ position: { x: expect.any(Number), y: expect.any(Number) } })); // objectContaining, with nested object, containing partial props/values // FAILS expect({ position: { x: 0, y: 0 } }).toEqual(expect.objectContaining({ position: { x: expect.any(Number) } })); // objectContaining, with nested object, also declared with objectContaining, containing partial props/values // PASSES expect({ position: { x: 0, y: 0 } }).toEqual(expect.objectContaining({ position: expect.objectContaining({ x: expect.any(Number) }) })); // toMatchObject, with nested object, containing full props/values // PASSES expect({ position: { x: 0, y: 0 } }).toMatchObject({ position: { x: expect.any(Number), y: expect.any(Number) } }); // toMatchObject, with nested object, containing partial props/values // PASSES expect({ position: { x: 0, y: 0 } }).toMatchObject({ position: { x: expect.any(Number) } });

Mi opinión es que expect.objectContaining ( y otros comparadores similares ) se pueden usar en lugar de valores literales dentro del "objeto" que pasa a otros comparadores.

Este ejemplo es de los documentos:

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

Entonces, aunque parecen hacer lo mismo en su ejemplo, los expect.* también son útiles de esta otra manera.

Incluso sin diferencias funcionales entre las dos construcciones, aquí hay un ejemplo de por qué expect.objectContaining , aunque largo y engorroso en comparación con toMatchObject , puede ser útil:

 describe('list of X', () => { it('should contain an element with a specific ID', () => { const listOfItems = uut.getItems(); expect(listOfItems).toContainEqual(expect.objectContaining({id: 'some-id'})); }); });

Incluso si listOfItems contiene elementos como tales (es decir, con campos que no sean solo el 'id') --

 [ {id: 'some-id', other: 'fields'}, {id: 'some-other-id', even: 'more-fields'} ]

aún expect.objectContaining permite una forma simple de implementar la comparación como se esperaría (es decir, basada estrictamente en la identificación); toMatchObject no se puede usar aquí en absoluto. Entonces, si bien toMatchObject es corto y legible, la construcción más larga de los dos es más genérica y permite una mayor flexibilidad, ya que se puede utilizar de formas que toMatchObject() no puede.