Add error serializer

[lukaselmer]

Clear and concise description of the problem

Custom errors with additional attributes are hard to test using toThrowErrorMatchingInlineSnapshot

Example:

class ErrorWithDetails extends Error {
  readonly details: unknown

  constructor(message: string, options: ErrorOptions & { details: unknown }) {
    super(message, options)
    this.details = options.details
  }
}

describe('ErrorWithDetails', () => {
  it('should throw an error with details', () => {
    expect(() => {
      throw new ErrorWithDetails('Example', { details: 'interesting detail' })
    }).toThrowErrorMatchingInlineSnapshot('"Example"') // 'interesting detail' is lost
  })
})

Suggested solution

Add an addErrorSerializer which works like addSnapshotSerializer, but for errors.

Example:

expect.addErrorSerializer({
  serialize(val, config, indentation, depth, refs, printer) {
    const error = val as ErrorWithDetails
    return `${error.message}: ${printer(error.details, config, indentation, depth, refs)}`
  },
  test(val) {
    return val && val instanceof ErrorWithDetails
  },
})

which could then result in:

class ErrorWithDetails extends Error {
  readonly details: unknown

  constructor(message: string, options: ErrorOptions & { details: unknown }) {
    super(message, options)
    this.details = options.details
  }
}

describe('ErrorWithDetails', () => {
  it('should throw an error with details', () => {
    expect(() => {
      throw new ErrorWithDetails('Example', { details: 'interesting detail' })
    }).toThrowErrorMatchingInlineSnapshot('"Example: interesting detail"')
  })
})

Alternative

We can work around that issue, but it is cumbersome:

class ErrorWithDetails extends Error {
  readonly details: unknown

  constructor(message: string, options: ErrorOptions & { details: unknown }) {
    super(message, options)
    this.details = options.details
  }
}

describe('ErrorWithDetails', () => {
  it('should throw an error with details', () => {
    expect(
      catchAndSerializeError(() => {
        throw new ErrorWithDetails('Example', { details: 'interesting detail' })
      })
    ).toMatchInlineSnapshot('"Example \\"interesting detail\\""')
  })
})

function catchAndSerializeError(fn: () => any) {
  try {
    fn()
    throw new Error('Expected an error')
  } catch (error) {
    if (error instanceof ErrorWithDetails) {
      return `${error.message} ${JSON.stringify(error.details)}`
    }
    throw new Error('Expected an ErrorWithDetails')
  }
}

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sheremet-va]

Can't you just use addSnapshotSerializer?

[lukaselmer]

Can't you just use addSnapshotSerializer?

I was hoping that, but no, that didn't work 😥

I think I also found the place where the error is converted, and there it's just if(error instanceof Error) return error.message

[sheremet-va]

Looks like a bug. I would assume it to be affected

[hi-ogawa]

Hi, I'm curious about this issue and I'd like to confirm what's expected to work or not work.

I'm experimenting with OP's example locally and I put reproduction at the bottom.
In summary, custom serializer seems to work like this currently:

• expect(someError).toMatchInlineSnapshot(...)
  • Serializer applied
• expect(() => { throw someError }).toThrowErrorMatchingInlineSnapshot(...)
  • Serializer not applied. Snapshot will become someError.message.

Could someone confirm whether custom serializer should be applied for 2nd case as well?

Given that first case works, I also included potential workaround for users in the snippet below.

reveal full snippet

test('custom serializer against thrown instance', async () => {
  class ErrorWithDetails extends Error {
    readonly details: unknown

    constructor(message: string, options: ErrorOptions & { details: unknown }) {
      super(message, options)
      this.details = options.details
    }
  }

  // without custom serializer
  const error = new ErrorWithDetails('Example', { details: 'interesting detail' })
  expect(() => {
    throw error
  }).toThrowErrorMatchingInlineSnapshot(`"Example"`)
  expect(error).toMatchInlineSnapshot(`[Error: Example]`)

  // with custom serializer
  expect.addSnapshotSerializer({
    serialize(val, config, indentation, depth, refs, printer) {
      const error = val as ErrorWithDetails
      return `${error.message}: ${printer(error.details, config, indentation, depth, refs)}`
    },
    test(val) {
      return val && val instanceof ErrorWithDetails
    },
  })
  expect(() => {
    throw error
  }).toThrowErrorMatchingInlineSnapshot(`"Example"`) // serializer not applied
  expect(error).toMatchInlineSnapshot(`Example: "interesting detail"`) // serializer applied

  //
  // workaround 1 (for async error)
  //   by unwrapping with `rejects, it can assert error instance via `toMatchInlineSnapshot`
  //
  await expect(async () => {
    throw error
  }).rejects.toMatchInlineSnapshot(`Example: "interesting detail"`)

  //
  // workaround 2
  //   create a utility to catch error and use it to assert snapshot via `toMatchInlineSnapshot`
  //
  function wrapError<T>(f: () => T): { success: true; data: T } | { success: false; error: unknown } {
    try {
      return { success: true, data: f() }
    }
    catch (error) {
      return { success: false, error }
    }
  }
  expect(wrapError(() => {
    throw error
  })).toMatchInlineSnapshot(`
    {
      "error": Example: "interesting detail",
      "success": false,
    }
  `)
})

---

While looking around the code, it looks like Error.message extraction for toThrowErrorMatchingInlineSnapshot happens here:

vitest/packages/vitest/src/integrations/snapshot/chai.ts

Lines 143 to 144 in ba1df84

	getSnapshotClient().assert({
	received: getErrorString(expected, promise),

But changing here might be a huge breaking change

function getErrorString(expected: () => void | Error, promise: string | undefined) {
  ...
  catch (e) {
-    return getErrorMessage(e)    
+    return e
  }
  ...
}

since this will lead to a different default throw snapshot:

// before
  expect(() => {
    throw new Error('omega')
  }).toThrowErrorMatchingInlineSnapshot(`"ometa"`)

// after
  expect(() => {
    throw new Error('omega')
  }).toThrowErrorMatchingInlineSnapshot(`[Error: omega]`)

EDIT: I created a draft PR as it might help the discussion better with concrete code. #4396

[lukaselmer]

@hi-ogawa I came to exactly the same conclusion. Before creating a PR, I wanted to confirm that this is really an issue. Thanks for creating the PR, looks promising!