turbo87 / eslint-plugin-chai-expect

ESLint plugin that checks for common chai.js expect() mistakes

eslint-plugin-chai-expect

ESLint plugin that checks for common chai.js expect() mistakes

Requirements

• Node.js 6 or above
• ESLint 4.x or 5.x or 6.x

Installation

npm install --save-dev eslint-plugin-chai-expect

Configuration

Add a plugins section and specify chai-expect as a plugin:

{
  "plugins": [
    "chai-expect"
  ]
}

Enable the rules that you would like to use:

{
  "rules": {
    "chai-expect/no-inner-compare": 2,
    "chai-expect/no-inner-literal": 2,
    "chai-expect/missing-assertion": 2,
    "chai-expect/terminating-properties": 2
  }
}

Or, if you just want the above defaults, you can avoid all of the above and just extend the config:

{
  "extends": ["plugin:chai-expect/recommended"]
}

Rules

• no-inner-compare - Prevent using comparisons in the expect() argument
• no-inner-literal - Prevent using literals in the expect() argument (undefined, null, NaN, (+|-)Infinity, this, booleans, numbers, strings, and BigInt or regex literals)
• missing-assertion - Prevent calling expect(...) without an assertion like .to.be.ok
• terminating-properties - Prevent calling to.be.ok and other assertion properties as functions

Additional configuration

terminating-properties rule

A number of extensions to chai add additional terminating properties. For example chai-http adds:

• headers
• html
• ip
• json
• redirect
• text

The terminating-properties rule can be configured to ensure these (or other) additional properties are not used as functions:

{
  "rules": {
    "chai-expect/terminating-properties": ["error", {
      "properties": ["headers", "html", "ip", "json", "redirect", "test"]
    }]
  }
}

License

eslint-plugin-chai-expect is licensed under the MIT License.

eslint-plugin-chai-expect's Issues

Prevent expect(true).to.be.false

... or any other primitive value inside expect() as this is usually a sign of a bug in the test code.

Example: ember-cli/ember-cli#6846

Combine with eslint-plugin-chai-friendly

Hey @Turbo87!

It would be nice if you could combine your plugin with @ihordiachenko's eslint-plugin-chai-friendly into a shared eslint-plugin-chai :)

That's even something you could submit to the other members of the https://github.com/chaijs org 🙂

---

EDIT: Counterpart of ihordiachenko/eslint-plugin-chai-friendly#5, sorry for the spam 😅

ESLint 9 / Flat config support

Hi,

As of ESLint 8, there is now a new format for ESLint config files which requires that plugins follow a specific format. In ESLint 9, this format will be the only one available by default (and other API changes have occurred in ESLint 9 that may affect this plugin).

Info:

1. https://eslint.org/docs/latest/use/configure/configuration-files-new
2. https://eslint.org/blog/2022/08/new-config-system-part-1/
3. https://eslint.org/blog/2022/08/new-config-system-part-2/
4. https://eslint.org/docs/latest/use/configure/migration-guide

Might you update to be compatible with the new format?

Thanks!

Support ESLint 7.x

ESLint v7.0.0 is released .

It would be awesome to have official ESLint 7 support for the release on npmjs.
As I can see, the master branch depends on eslint@^7.0.0 already, but the peerDependency is still "peerDependencies": {"eslint": ">=2.0.0 <= 6.x"}.

At least one assertion

Thanks for the great work.

Would love to hear your thoughts on a check that ensure a test has at least 1 assertion (otherwise it is not doing anything...). Are you aware of one like this? would you appreciate such a PR?

Prefer .to.be.true over .to.equal(true)

Hi @Turbo87,

out team is considering to add a rule that would fail lint if we use .to.be.true instead of .to.equal(true) and also .to.be.false instead of .to.equal(false).

Would you be open to implementing such a feature (yourself or us via PR)?

EDIT: The rule could be called chai-expect/formatting-boolean and configurable to be preferred to one or the other case.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/checkout action to v4
• Update actions/setup-node action to v4
• Update dependency chai to v5
• Update dependency eslint to v9
• Update dependency import-from to v4
• Update dependency mocha to v10
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

github-actions

.github/workflows/ci.yml

• actions/checkout v3
• actions/setup-node v3
• actions/checkout v3
• actions/setup-node v3
• actions/checkout v3
• actions/setup-node v3

.github/workflows/release.yml

• actions/checkout v3
• actions/setup-node v3

npm

package.json

• chai 4.4.1
• eslint 8.57.0
• import-from 3.0.0
• mocha 9.2.2
• nyc 15.1.0
• eslint >=2.0.0 <= 8.x
• node 10.* || 12.* || >= 14.*

---

• Check this box to trigger a request for Renovate to run again on this repository

Rule to prevent no-op expect.to.throw with missing parentheses at end

Example code the rule would detect:

expect(() => {
    console.log("Foo");
}).to.throw;

In this example, the inner lambda is never even run! And the test passes despite the code not throwing anything. This is an easy mistake to make since other Chai assertions don't end in parens, e.g. expect(...).to.be.false;.

The 'intended' correct code would be:

expect(() => {
    console.log("Foo");
}).to.throw();  // <-- note parens at end

Ideally (maybe this is a whole separate feature request though 🙂), there could also be a way to mandate that the parens are non-empty. For example, if a team wants to mandate the best practice that you expect a specific error class or message, rather than any old error at all (including an accidental NPE) causing the test to pass.

Example better / best practice:

expect(() => {
    console.log("Foo");
}).to.throw(PermissionsError);

or

expect(() => {
    console.log("Foo");
}).to.throw("Unable to access user record");

missing-assertion doesn't raise warning when return+expect without assertion

missing-assertion rule doesn't raise any warning when there is a return combined with an expect without assertion.

	describe('calculateFee', () => {
		it('should return the correct fee for delegate transaction', () => {
                         // Missing assertion false positive
			return expect(delegate.calculateFee(transaction).isEqualTo(FEES.DELEGATE));
		});
	});

Add 'json' to the terminating-properties rule

Currently the 'terminating-properties' rule will not pick up on the incorrect usage of expect(result).to.be.json()

npm release

Thanks very much for your promptness on all the reviewing and merges...

Are you ok for a new npm release now?

terminating-properties missing on last release (1.0.0)

It was created after release 1.0.0
And no release was created after it

npm release

Thanks very much for your promptness on all the reviewing and merges.
Are you ok for a new npm release now?

It doesn't work for me

My config is

"plugins": [
    "chai-expect", "react", "import"
],
rules: {
"chai-expect/missing-assertion": 0,
"chai-expect/terminating-properties": 0
}

but eslint still have error alert for this line

expect(AV.User.current()).is.not.be.ok;

Add recommended config

I'd just like to suggest making things a little simpler by offering a "recommended" config which enables all of the rules (and adds to plugins automatically), so one only need to add your plugin to extends...