vitest-fail-on-console: Stop Ignoring console.error in Your Tests

All tests pass, but the terminal is full of red console.error output. This is common and easy to ignore — the tests passed, after all. But those errors don’t appear out of nowhere. Something went wrong; nobody just noticed.

vitest-fail-on-console does one thing: if console.error or console.warn appears during a test, that test fails. It forces you to acknowledge these messages instead of letting them drown in noise.

Why console.error in Tests Is a Code Smell

Vitest doesn’t care about console output by default. You can console.error all day and tests still pass.

The problem is that console.error usually means something. It might be:

A React prop type warning
An async error that was caught but not properly handled
A third-party package telling you you’re using it wrong
An error handler in your own code getting triggered

When these appear in tests, the test is running in a slightly broken state — it just didn’t throw. Over time the test output becomes pure noise. Nobody reads it anymore, and the real signals get buried.

vitest-fail-on-console flips this: make console output a test failure, so you’re forced to address it.

Installation

1
npm install -D vitest-fail-on-console

Setup

Import and call it in your setup file:

1
2
3
4
// tests/setup.ts
import failOnConsole from 'vitest-fail-on-console'

failOnConsole()

Then wire up the setup file in vitest.config.ts:

1
2
3
4
5
6
7
import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    setupFiles: ['tests/setup.ts'],
  },
})

That’s it. Any test that triggers console.error or console.warn will now fail.

Options

failOnConsole() accepts an options object to control which console methods trigger failures:

1
2
3
4
5
6
7
8
failOnConsole({
  shouldFailOnError: true,   // default true
  shouldFailOnWarn: true,    // default true
  shouldFailOnLog: false,    // default false
  shouldFailOnInfo: false,   // default false
  shouldFailOnDebug: false,  // default false
  shouldFailOnAssert: false, // default false
})

error and warn are usually enough. Whether to include log / info / debug depends on your project’s conventions.

allowMessage

Allow specific messages through without failing — useful for known third-party issues you can’t fix right now:

1
2
3
4
5
failOnConsole({
  allowMessage: (message) => {
    return /ResizeObserver loop limit exceeded/.test(message)
  },
})

silenceMessage

Like allowMessage, but also suppresses the console output entirely:

1
2
3
4
5
failOnConsole({
  silenceMessage: (message) => {
    return /Not implemented: navigation/.test(message)
  },
})

skipTest

Skip specific test files or test names entirely:

1
2
3
4
5
failOnConsole({
  skipTest: ({ testPath, testName }) => {
    return testPath.includes('/legacy/')
  },
})

afterEachDelay

Sometimes async operations call console methods after a test ends. This option adds a delay before checking:

1
2
3
failOnConsole({
  afterEachDelay: 100, // wait 100ms, default is 0
})

Handling Expected console.error Calls

After installing vitest-fail-on-console, if a test is specifically verifying that console.error gets called, letting it fire naturally will cause the test to fail.

The correct approach is to mock it with vi.spyOn:

1
2
3
4
5
6
7
8
9
it('logs an error when request fails', () => {
  // mock it so the message doesn't actually reach the console
  vi.spyOn(console, 'error').mockImplementation(() => {})

  triggerSomethingThatLogsError()

  // assert it was called with the expected message
  expect(console.error).toHaveBeenCalledWith('Request failed')
})

This does two things: the test explicitly declares “I know an error will be logged here,” and it asserts the exact message. Much stricter than silently letting console.error through.

Pair It with a Clean Test Environment

vitest-fail-on-console handles the console output side. If your tests also have I/O boundaries to replace — filesystem, file watchers — you can pair it with memfs using the same philosophy: every aspect of the test environment should be under your control.

See Testing a Filesystem Service with memfs + FakeWatchService for that approach.