Why is this an issue?

Disabling unit tests lead to a lack of visibility into why tests are ignored, a decline in code quality as underlying problems remain unaddressed, and an increased maintenance burden due to the accumulation of disabled tests. It can also create a false sense of security about the stability of the codebase and pose challenges for new developers who may lack the context to understand why tests were disabled. Proper documentation and clear reasons for disabling tests are essential to ensure they are revisited and re-enabled once the issues are resolved.

This rule raises an issue when a test construct from Jasmine, Jest, Vitest, Mocha, Cypress, Playwright, or Node.js Test Runner is disabled without providing an explanation. It relies on the presence of a package.json file and looks at the dependencies to determine which testing framework is used.

How to fix it in Jasmine

A comment should be added before, on, or after the line of the unit test explaining why the test was disabled. Alternatively, if the test is no longer relevant, it should be removed entirely.

Code examples

Noncompliant code example

describe('foo', function() {
  xit('should do something', function(done) { // Noncompliant
    done();
  });
});

Compliant solution

describe('foo', function() {
  // Reason: There is a bug in the code
  xit('should do something', function(done) { // Compliant
    done();
  });
});

How to fix it in Jest

A comment should be added before, on, or after the line of the unit test explaining why the test was disabled. Alternatively, if the test is no longer relevant, it should be removed entirely.

Code examples

Noncompliant code example

describe('foo', function() {
  test.skip('should do something', function(done) { // Noncompliant
    done();
  });
});

Compliant solution

describe('foo', function() {
  // Reason: There is a bug in the code
  test.skip('should do something', function(done) { // Compliant
    done();
  });
});

How to fix it in Vitest

A comment should be added before, on, or after the line of the unit test explaining why the test was disabled. Alternatively, if the test is no longer relevant, it should be removed entirely.

This recommendation applies to it.skip(...), test.skip(...), describe.skip(...), and suite.skip(...).

Code examples

Noncompliant code example

describe('foo', function() {
  test.skip('should do something', function(done) { // Noncompliant
    done();
  });
});

Compliant solution

describe('foo', function() {
  // Reason: There is a bug in the code
  test.skip('should do something', function(done) { // Compliant
    done();
  });
});

How to fix it in Mocha

A comment should be added before, on, or after the line of the unit test explaining why the test was disabled. Alternatively, if the test is no longer relevant, it should be removed entirely.

In Mocha, this recommendation applies to the standard .skip APIs and to the x-prefixed aliases such as xit(...), xspecify(...), xdescribe(...), and xcontext(...). The same guidance applies to Cypress, which uses Mocha-style test definitions.

Code examples

Noncompliant code example

describe('foo', function() {
  it.skip('should do something', function(done) { // Noncompliant
    done();
  });
});

Compliant solution

describe('foo', function() {
  // Reason: There is a bug in the code
  it.skip('should do something', function(done) { // Compliant
    done();
  });
});

How to fix it in Playwright

A comment should be added before, on, or after the line of the skipped test or test suite explaining why it was disabled. Alternatively, if the test is no longer relevant, it should be removed entirely.

This recommendation applies to definition-style skipped tests and suites such as test.skip('title', ...) and test.describe.skip('title', ...). It does not apply to runtime conditional annotations such as test.skip(callback, description).

Code examples

Noncompliant code example

const { test } = require('@playwright/test');

test.skip('should do something', async ({ page }) => { // Noncompliant
  await page.goto('https://example.com');
});

Compliant solution

const { test } = require('@playwright/test');

// Reason: There is a bug in the code
test.skip('should do something', async ({ page }) => { // Compliant
  await page.goto('https://example.com');
});

How to fix it in Node.js

A non-empty string literal should be passed to the skip options or as an argument to the call to skip ({ skip: 'reason' }) on the test context (t.skip('reason')), explaining why the test was disabled.

Code examples

Noncompliant code example

const test = require('node:test');

test('should do something', { skip: true }, function(t) { // Noncompliant
  t.assert.ok(true);
});

test('should do something', function(t) {
  t.skip(); // Noncompliant
});

Compliant solution

const test = require('node:test');

test('should do something', { skip: 'There is a bug in the code' }, function(t) { // Compliant
  t.assert.ok(true);
});

test('should do something', function(t) {
  t.skip('There is a bug in the code'); // Compliant
});

Resources

Documentation