How to check if toThrowError is throwing an error with specific properties?

[gajus]

I need to write a check that effectively checks values of error properties. In ava I was able to do it in such a way:

test('throws', async t => {
  const error = await t.throwsAsync(foo());

  t.true(error instanceof IntegrityConstraintViolationError);
  t.is(error.message, 'Query violates a check integrity constraint.');
  t.is(error.cause.message, 'violates check constraint "ledger_transaction_entry_amount_positive');
  t.is(error.cause.constraint, 'ledger_transaction_entry_amount_positive');
});

Whereas with Vitest it seems I am only able to assert what is the top level error message.

Looks like you can do this:

).rejects.toThrow(
  expect.objectContaining({
    cause: expect.any(Error),
    message: 'Query violates a check integrity constraint.',
  }),
);

but the error when it doesn’t match is so useless, e.g.

).rejects.toThrow(
  expect.objectContaining({
    cause: {
      message: 'foobar',
    },
    message: 'Query violates a check integrity constraint.',
  }),
);

The error it produces is:

FAIL  tests/contra-database/ledger/transactions.test.ts > can't have transaction entries with $0 amount
AssertionError: expected error to match asymmetric matcher
 ❯ tests/contra-database/ledger/transactions.test.ts:180:3
    178|
    179| test.only("can't have transaction entries with $0 amount", async () => {
    180|   await expect(
       |   ^
    181|     runWithDatabaseConnectionPool('contra_api', async ({ pool }) => {
    182|       await pool.transaction(async (transaction) => {

I would expect object to be dumped showing what didn't match.

[gajus]

I am not sure what is the proper answer to this, but I ended up writing a custom matcher:

import { randomUUID as uuid } from 'node:crypto';
import { serializeError } from 'serialize-error';
import { match } from 'tcompare';
import { beforeEach, expect } from 'vitest';

beforeEach(() => {
  globalThis.TEST_RUN_ID = uuid();
});

expect.extend({
  toMatchErrorObject(received, expected) {
    const result = match(serializeError(received), expected);

    return {
      message: () =>
        `Expected errors to match:\n${result.diff}\nReceived:\n${JSON.stringify(
          serializeError(received),
          null,
          2,
        )}`,
      pass: result.match,
    };
  },
});

This produces a nice error when things don't go according to plan:

Error: Expected errors to match:
--- expected
+++ actual
@@ -1,3 +1,3 @@
 Object {
-  "message": "Query violates a check integrity constraint.a",
+  "message": "Query violates a check integrity constraint.",
 }

Received:
{
  "cause": {
    "length": 369,
    "name": "error",
    "severity": "ERROR",
    "code": "23514",
    "detail": "Failing row contains (1, 1, 2, DEBIT, 0.00000000, 2023-10-26 15:42:18.202113+00, 2023-10-26 15:42:18.202113+00).",
    "schema": "public",
    "table": "ledger_transaction_entry",
    "constraint": "ledger_transaction_entry_amount_positive",
    "file": "execMain.c",
    "line": "1934",
    "routine": "ExecConstraints",
    "message": "new row for relation \"ledger_transaction_entry\" violates check constraint \"ledger_transaction_entry_amount_positive\""
  },
  "constraint": "ledger_transaction_entry_amount_positive",
  "column": null,
  "table": "ledger_transaction_entry",
  "notices": [],
  "name": "CheckIntegrityConstraintViolationError",
  "message": "Query violates a check integrity constraint."
}

[gajus]

@antfu Would be nice to have this in the core.

[sheremet-va]

There is this.equals that will also take async matchers into account. And if you return "actual" and "received" as properties, it will show a diff.

[gajus]

What is this equals? I don't see it in the documentation.

[sheremet-va]

It is listed as one of the methods on the context: https://vitest.dev/guide/extending-matchers.html#extending-matchers

[sheremet-va]

I would expect object to be dumped showing what didn't match.

Your solution looks correct, but the fact that it doesn't show a diff looks like a bug.

[kettanaito]

Raising a related discussion to improve error assertions: #5697 (particularly focusing on asserting cause).