tlvince / eslint-plugin-jasmine

ESLint rules for Jasmine

eslint-plugin-jasmine

ESLint rules for Jasmine

Usage

1. Install eslint-plugin-jasmine as a dev-dependency:

   npm install --save-dev eslint-plugin-jasmine

2. Enable the plugin by adding it to your .eslintrc:

   plugins:
     - jasmine

ESLint itself provides a Jasmine environment for Jasmine's global variables. It's therefore recommended to also enable it in your .eslintrc:

plugins:
  - jasmine
env:
  jasmine: true

By default, no rules are enabled. See the next section for more.

Configuration

This plugin exports a recommended configuration that enforces good practices.

To enable this configuration, use the extends property in your .eslintrc config file:

plugins:
  - jasmine
env:
  jasmine: true
extends: 'plugin:jasmine/recommended'

See the ESLint config docs for more information about extending configuration files.

Rules

Rule	Recommended	Options
expect-matcher	1,
expect-single-argument	1,
missing-expect	0, 'expect()', 'expectAsync()'	expectation function names
named-spy	0
new-line-before-expect	1
new-line-between-declarations	1
no-assign-spyon	0
no-describe-variables	0
no-disabled-tests	1
no-expect-in-setup-teardown	1, 'expect()', 'expectAsync()'	expectation function names
no-focused-tests	2
no-global-setup	2
no-pending-tests	1
no-promise-without-done-fail	1
no-spec-dupes	1, 'block'	['block', 'branch']
no-suite-callback-args	2
no-suite-dupes	1, 'block'	['block', 'branch']
no-unsafe-spy	1
valid-expect	deprecated
prefer-jasmine-matcher	1
prefer-promise-strategies	1
prefer-toHaveBeenCalledWith	1
prefer-toBeUndefined	0	['always', 'never']

For example, using the recommended configuration, the no-focused-tests rule is enabled and will cause ESLint to throw an error (with an exit code of 1) when triggered.

You may customise each rule by adding a value in your .eslintrc rules property:

plugins:
  - jasmine
env:
  jasmine: true
rules:
  jasmine/no-focused-tests: 0
  jasmine/no-suite-dupes:
    - 2
    - branch

See configuring rules for more information.

Author

© 2016 - 2017 Tom Vincent [email protected] and contributors.

License

Released under the MIT license.

eslint-plugin-jasmine's Issues

support node 4

#Hi,

I think this package should support node >= 4, not node >= 6, to be aligned with ESLint.

The 2.0.0 release notes were misleading. It says "This module no longer supports Node.js 0.10" but doesn't say it only supports node >= 6. This broke when installing with yarn on node 4 because yarn checks engines in package.json.

Error after upgrading to version 1.5.1

After upgrading to v1.5.1 and running lint I get an error:

/home/krymen/workspace/my-project/ui/node_modules/eslint-plugin-jasmine/lib/prohibit.js:8
      var result = node.callee && node.callee.name.match(regex);
                                                   ^
TypeError: Cannot call method 'match' of undefined

no-promise-without-done-fail

Do you want to request a feature or report a bug?
I would like to suggest a new rule to make sure that there are no tests with promises without handling rejection flow. It is common to check only happy flows and in this case jasmine will fail with timeout instead of showing a real error.

What is the current behavior?
There is no such rule

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
In case of am async test with promises there must also be a done.fail inside catch.

Please mention your node.js, eslint-plugin-jasmine and operating system version.

Update to ESLint v1.x

Add version to package.json

Please add the version property to package.json as specified in https://docs.npmjs.com/files/package.json#version

tomastrajan/jasmine-async-sugar support

Do you want to request a feature or report a bug?
feature-request - or point me to where I could add it/configure it.

What is the current behavior?
I'm using Jasmine-Async-Sugar: https://github.com/tomastrajan/jasmine-async-sugar

Now jasmine/no-unsafe-spy reports a warning, when I use jasmine.createSpy in an itAsync-Block.

What is the expected behavior?

I would like to add the itAsync-Block as a safe place to create Spys. Maybe this is configurable? Maybe it should be added in the code? Please tell me how to do it or how you would like it to be fixed.

Please mention your node.js, eslint-plugin-jasmine and operating system version.
node v6.4.0
"eslint-plugin-jasmine": "^1.8.1"
Windows 10

new-line-before-expect improvement

The following example I feel it should not trigger a new-line-before-expect warning:

it("should do something", function () {
  var a = 3;

  expect(a).toBeDefined();
  expect(a).toBe(3);
});

Skeptical about new rule prefer-toHaveBeenCalledWith

I'm skeptical about the new rule prefer-toHaveBeenCalledWith. I understand that very often you want to check arguments to a spy call. But sometimes, what you care about is just that the call happened, you don't care about what were the arguments. This is for example the case when arguments are tested differently, somewhere else.

Unable to install master version via github, last release seems somewhat out of date

The last version, 1.6, is giving me problems with current versions of eslint (can't find the rulesets). It looks like the master branch has changed since 1.6, though. I tried installing directly from github with NPM and that currently does not work (for me, anyway).

Sorry, that's a bit scatterbrained.

'describe' is not defined no-undef error

Hej,
This must be my lack of understanding, but when i add this plugin to my eslint configuration and run it i get these errors:

3:1 error 'describe' is not defined no-undef
4:5 error 'it' is not defined no-undef
5:9 error 'expect' is not defined no-undef
7:5 error 'it' is not defined no-undef
8:9 error 'expect' is not defined no-undef

My .eslintrc looks like this:

{
  "plugins": ["jasmine"],
  "extends": ["angular", "eslint:recommended", "plugin:jasmine/recommended"],
  "rules": {
    "quotes": [ 2, "single"],
    "strict": [2, "global"],
    "semi": ["error", "always"],
    "angular/on-watch": "warn"
  }
}

And in my package.json i have version ^2.3.0 for eslint and ^1.8.1 for eslint-plugin-jasmin.

Any help/pointers are appreciated.

Rule `no-unsafe-spy` does not detect `jasmine.createSpyObj`

Do you want to request a feature or report a bug?
It is rather bug than feature

What is the current behavior?
If you declare outside of before/after/it block

let someSpyObj = jasmine.createSpyObj('spyObj', ['spyMethod']);

warning will not be shown

If the current behavior is a bug, please provide the steps to reproduce.
Use jasmine.createSpyObj outside of before/after/it block

What is the expected behavior?
Warning should be shown when jasmine.createSpyObj is used outside of before/after/it block

Please mention your node.js, eslint-plugin-jasmine and operating system version.
node.js v7.2.1
eslint-plugin-jasmine v2.2.0

no-suite-dupes should have nesting options

Thanks for this plugin, it's proven useful already in using ESLint with conjunction with our test suite.

I'm not really sure how to best say this because I'm new to unit testing altogether but normally we are writing our tests with a suite like this:

describe('DashboardView', function() {
    ...

    describe('on render', function() {
        ...
    });
});

We then have another set of tests in a different file for a different view:

describe('FiltersView', function() {
    ...

    describe('on render', function() {
        ...
    });
});

These are backbone views and we are testing some of their functionality. If I turn on no-suite-dupes I get a warning for the FiltersView (which comes second). It would be nice to have an option to have the dupes check on the same levels (so main level can't dupe, nested levels can't dupe, nested levels of nested levels can't dupe, etc).

Thoughts?

Rule `no-unsafe-spy` is failed when `jasmine.createSpy` is used in function which is defined outside but called inside before/after/it

Do you want to request a feature or report a bug?
I suppose it is rather new feature than bug

What is the current behavior?

describe('suite', function () {
	beforeEach(function () {
		initSpies();
	});
});

function initSpies() {
	return {
		params: {},
		getData: jasmine.createSpy('getData'),
		getValidations: jasmine.createSpy('getValidations')
	};
}

For code above next warning will be shown warning Spy declared outside of before/after/it block jasmine/no-unsafe-spy

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
Warning should not be shown if function initSpies is called only from before/after/it block

Please mention your node.js, eslint-plugin-jasmine and operating system version.
node.js v7.2.1
eslint-plugin-jasmine v2.2.0

Improve valid-expect to catch defined but not called matchers

Currently, valid-expect does not warn about the following invalid expect() usage:

expect(something).toBeDefined

In this case toBeDefined is there but not called.

Let me know if this makes sense to improve. If yes, I can prepare a PR. Thanks.

Getting Error: ESLint: Cannot read property 'body' of undefined

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Intermitently while editing tests in VSCode I am getting an error:
ESLint: Cannot read property 'body' of undefined. Please see the 'ESLint' output channel for details.
In the output channel I have:

[Error - 16:28:30] ESLint stack trace:
[Error - 16:28:30] TypeError: Cannot read property 'body' of undefined
    at getDescribeDeclarationsContent (c:\Src\Repos\html5-training\server\node_modules\eslint-plugin-jasmine\lib\rules\new-line-between-declarations.js:46:80)
    at CallExpression (c:\Src\Repos\html5-training\server\node_modules\eslint-plugin-jasmine\lib\rules\new-line-between-declarations.js:17:28)
    at listeners.(anonymous function).forEach.listener (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\util\safe-emitter.js:47:58)
    at Array.forEach (native)
    at Object.emit (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\util\safe-emitter.js:47:38)
    at NodeEventGenerator.applySelector (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\util\node-event-generator.js:251:26)
    at NodeEventGenerator.applySelectors (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\util\node-event-generator.js:280:22)
    at NodeEventGenerator.enterNode (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\util\node-event-generator.js:294:14)
    at CodePathAnalyzer.enterNode (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\code-path-analysis\code-path-analyzer.js:608:23)
    at Traverser.enter [as _enter] (c:\Src\Repos\html5-training\server\node_modules\eslint\lib\linter.js:1006:32)

It looks like there is just an extra check that is required on line 46 of new-line-between-declarations.js:

if (describe.arguments && describe.arguments[1] && describe.arguments[1].body.body) {
  ...
}

should be:

if (describe.arguments && describe.arguments[1] && describe.arguments[1].body && describe.arguments[1].body.body) {
  ...
}

I could raise a PR if you would accept it?

If the current behavior is a bug, please provide the steps to reproduce.
Setup ESLint in VsCode, with the jasmine plugin and create some tests. Every now and then you will get this error.

It seems to occur when creating a describe immediately after another:

describe("some behaviour", function() {
  ...
});
describe("", function);

when you get to this point in writing the second describe, VSCode reports the error. presumably becasue there is no body on the second function yet...

What is the expected behavior?
I wouldn't expect to ESlint to recieve an exception.

Please mention your node.js, eslint-plugin-jasmine and operating system version.
Node: v8.9.4
ESLint-Plugin-Jasmine: v2.9.1
VSCode: 1.20.1
OS: Windows 10

new-line-before-expect fails when returning or awaiting an expect

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Returning and awaiting an expect results in a rule failure

If the current behavior is a bug, please provide the steps to reproduce.
Here are some examples:

test('resolves to lemon', () => {
  return expect(Promise.resolve('lemon')).resolves.toBe('lemon');
});

test('resolves to lemon', async () => {
  await expect(Promise.resolve('lemon')).resolves.toBe('lemon');
  await expect(Promise.resolve('lemon')).resolves.not.toBe('octopus');
});

Both from Jest's docs.
What is the expected behavior?
Return/awaiting expects should not fail
Please mention your node.js, eslint-plugin-jasmine and operating system version.
node: v8.9.0
eslint-plugin-jasmine: 2.9.3
os: 10.12.6

Update loc for no-disabled-tests / no-focussed-tests

Do you want to request a feature or report a bug?

Improvement.

What is the current behavior?

Visually annoying loc that covers whole function.

What is the expected behavior?

Nice loc that covers function name only.

---

Can make PR.

valid-expect does not handle "not" assertions properly

This looks like a bug to me. The valid-expect rule is complaining about a matcher not being called if there is a .not type assertion:

expect("text1").not.toEqual("text2");

Using the latest eslint-plugin-jasmine. Can work on a fix. Thanks.

No expect in beforeEach, afterEach, beforeAll and afterAll

Would it make sense to prohibit the usage of expect() inside beforeEach, afterEach, beforeAll and afterAll?

If yes, I can work on making the PR. Thanks.

Detect test scenarios using promises and not using done callback

Imho we should warn about such bugs:

it('should be invalid', function () {
    doSomeAsyncStuff().then(function () {
        expect(true).toBe(false);
    });
});

This test, when run, will pass, but some other test later will fail. This is the correct, fixed version:

it('should be invalid', function (done) {
    doSomeAsyncStuff().then(function () {
        expect(true).toBe(false);
    }).catch(fail).then(done);
});

This was actually a pretty common bug for me.

Rule suggestion: prefer-tobe

For whatever reason, people have a tendency to write:

expect(a === b).toBeTuthy();

The linter could suggest that they instead write:

expect(a).toBe(b);

That is easier to read and gives a much more meaningful error message.

Rule suggestion: newline-before-expect

I suggest adding a new rule: newline-before-expect, which will serve the same purpose newline-before-return does, except for expect.

expect usually is like return but for specs [: Clearly delineating where a spec is running an expectation can greatly increase the readability and clarity of the code.

For the use case check this issue on eslint.

I suggest adding it with the following options:

everyExpect: tells to add a new-line before every expect in a spec. Sometimes developers put multiple expect-s in one spec (btw we should add a rule to limit an it function so that it has only one expectation) and this option tells should a new line be added before every expect or only before the first in the series of lines with expect. Default: false.

minBlockSize: tells when to force a newline before expect. Example:

  it('returns a passed keyCode', function() {
    var keyboardEvent = createEvent({type: 'keyup', keyCode: 40});

    expect(keyboardEvent.which).toBe(40);
  });

In such a small function I'd rather not have a newline before expect keyword. However, in this function I would like to have one.

  it('returns whatever getEventCharCode returns', function() {
    getEventCharCode.mockReturnValue(9001);
    var keyboardEvent = createEvent({type: 'keypress', charCode: 50});

    expect(keyboardEvent.which).toBe(9001);
  });

Default: 0 (forced in every function).

If you're interested, I can add more info for clarity and even implement it afterwards. What do you think?

Rule suggestion: no-tohavebeencalled

toHaveBeenCalled should be replaced with toHaveBeenCalledWith to ensure that functions are properly called and receive the right arguments.

Fix npm deployment

See https://travis-ci.org/tlvince/eslint-plugin-jasmine/builds/73438214#L223

breaking changes

Do you want to request a feature or report a bug?
bug
What is the current behavior?
undefined exception

If the current behavior is a bug, please provide the steps to reproduce.
After this commit:
99c458d

My build gets this message:
TypeError: Cannot read property 'start' of undefined at isFirstNodeInSuiteOrTest

What is the expected behavior?

Please mention your node.js, eslint-plugin-jasmine and operating system version.
eslint-plugin-jasmine version: 2.6.0
node: 7.7.1

I'd love to help maintain this project

@tlvince didn't know where else to post this: I'd love to help maintain this project

named-spy throws if spy is chained

const getStateMock = jasmine.createSpy('getState').and.returnValue(stateMock)

Cannot read property 'name' of undefined
TypeError: Cannot read property 'name' of undefined
    at EventEmitter.CallExpression (/home/testyo/repos/frontend-repo/code/node_modules/eslint-plugin-jasmine/lib/rules/named-spy.js:31:56)
    at emitOne (events.js:82:20)
    at EventEmitter.emit (events.js:169:7)
    at NodeEventGenerator.enterNode (/home/testyo/repos/frontend-repo/code/node_modules/eslint/lib/util/node-event-generator.js:42:22)
    at CodePathAnalyzer.enterNode (/home/testyo/repos/frontend-repo/code/node_modules/eslint/lib/code-path-analysis/code-path-analyzer.js:608:23)
    at CommentEventGenerator.enterNode (/home/testyo/repos/frontend-repo/code/node_modules/eslint/lib/util/comment-event-generator.js:98:23)
    at Controller.module.exports.api.verify.traverser.traverse.enter (/home/testyo/repos/frontend-repo/code/node_modules/eslint/lib/eslint.js:869:36)
    at Controller.__execute (/home/testyo/repos/frontend-repo/code/node_modules/eslint/node_modules/estraverse/estraverse.js:397:31)
    at Controller.traverse (/home/testyo/repos/frontend-repo/code/node_modules/eslint/node_modules/estraverse/estraverse.js:501:28)
    at Controller.controller.traverse (/home/testyo/repos/frontend-repo/code/node_modules/eslint/lib/util/traverser.js:38:33)

cc @remcohaszing

Investigate no-unsafe-spy performance

the current implementation looks for parent nodes, but an approach that takes advantage of the AST traversal could be more performant

we need to benchmark the performance of both approaches and refactor accordingly

Refactor no-expect-in-setup-teardown, missing-expect and no-global-setup rules to not violate DRY

no-expect-in-setup-teardown and missing-expect share the same buildName function.

no-expect-in-setup-teardown and no-global-setup share the same regular expression for the setup/teardown regular expression pattern.

It would be a good idea to not violate DRY principle and extract the common parts into a reusable library/configuration module.

beforeAll inside describe.only triggers no-global-setup

Do you want to request a feature or report a bug?

bug

What is the current behavior?

describe.only('suite', () => {

  beforeAll(() => { /* localsetup */ }); // 'Do not use `beforeAll` outside a `describe` except for in global helpers.

});

What is the expected behavior?

No warning.

The prefer-toHaveBeenCalledWith rule name isn't consistent with other rule names.

Rule names should be snake-case to be consistent with ESLint rules. prefer-toHaveBeenCalledWith violates this consistency. It should instead be prefer-to-have-been-called-with.

Enforce the uniqueness of a suite title

From time to time while reviewing the changes brought by other testers in the team, I'm seeing a copy-paste error - the describe name for a newly implemented test does not correspond to what is actually tested and repeats the name of another describe block somewhere inside the test directory.

For example (artificial):

describe("Testing username validation", function () {

   it("should allow 2 chars minimum", function () {
       // ...
   });

});

describe("Testing username validation", function () {

   it("Should check the password strength", function () {
       // ...
   });

});

Here, the second suite should be called Testing password validation, but the author forgot to change the suite name.

Would it make sense to have a eslint rule checking for the uniqueness of suite names?

If it does not make sense to have a reusable rule, feel free to close the ticket. Thank you!

Enforce it() names to start with "should"

Would it make sense to enforce that the it() name has to start with "should"? E.g. this would issue a warning:

it("some test I have", function () { });

This would not:

it("should test something", function () { });

Thanks.

"New line between declarations" warning at top of each test file

Do you want to request a feature or report a bug?

I believe this is a bug, but I could be wrong about the expected behaviour.

What is the current behavior?

Currently, the first describe() call in any file is marked by eslint as if it's in violation of the new-line-between-declarations rule

If the current behavior is a bug, please provide the steps to reproduce.

Here's a screenshot of what I see in Atom, using the linter-eslint package:

And in the status bar:

What is the expected behavior?

For the first line not to trigger this warning.

Please mention your node.js, eslint-plugin-jasmine and operating system version.

Operating System: macOS 10.12.5
eslint: 4.1.1
eslint-plugin-jasmine: 2.6.2
linter-eslint 8.2.1

Add a CallExpression condition test for v1.5.2

See #21.

Missing coverage for a2e081e

Enforce one assertion per test

Would it be a good idea to have eslint-plugin-jasmine report if there are more than one expect() calls per it() block? (http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html)

At least, we can have the rule disabled by default..

Thanks.

Add configuration to disable rules

I'm getting eslint warnings for jasmine/no-suite-dupes when I have suites that use variables in their name.

this is pretty rudimentary. In my code, I have a lot more it suites and more logic, but that gets in the way of the example:

let queue= [true, true, false],
    shouldReturnFalse = (state) => {
    describe(`from ${state}`), () => {
        it('should return false', () => {
            expect(result).toBe(false)
        })
    }),
    shouldReturnTrue = (state) => {
    describe(`from ${state}`), () => {
        it('should return true', () => {
            expect(result).toBe(true)
        })
    })

describe('object', () => {
    let result
    beforeEach(() => {
        result = queue.pop()
    }
    shouldReturnTrue(1)
    shouldReturnTrue(2)
    shouldReturnFalse(3)
})

Running eslint on the spec generates this warning:

  112:17  warning  Duplicate suite: "from null"                             jasmine/no-suite-dupes

Like other eslint rules, I would like to configure eslint-plugin-jasmine to ignore jasmine/no-suite-dupes, but the documentation does not provide this mechanism

Definition for rule was not found

I'm trying to use this plugin. I have this package.json:

{
  "name": "eslint-jasmine-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "eslint": "^2.3.0",
    "eslint-plugin-jasmine": "^1.6.0"
  }
}

This eslintrc:

{
  "plugins": [
    "jasmine"
  ],
  "rules": {
    "named-spy": 0,
    "no-focused-tests": 2,
    "no-disabled-tests": 1,
    "no-suite-dupes": 1,
    "no-spec-dupes": 1,
    "missing-expect": 0,
    "no-suite-callback-args": 2
  }
}

I run ./node_modules/.bin/eslint witherror.js and I get these errors:

/tmp/eslint-jasmine-test/witherror.js
  1:1  error    Definition for rule 'no-focused-tests' was not found        no-focused-tests
  1:1  warning  Definition for rule 'no-disabled-tests' was not found       no-disabled-tests
  1:1  warning  Definition for rule 'no-suite-dupes' was not found          no-suite-dupes
  1:1  warning  Definition for rule 'no-spec-dupes' was not found           no-spec-dupes
  1:1  error    Definition for rule 'no-suite-callback-args' was not found  no-suite-callback-args

Does this plugin not work with jasmine 2?

no-spec-dupes branch scoping fails when describe blocks are defined with template literals as the name

I have a few specs that use template literal strings as the titles. The it blocks beneath seem to get grouped together as one big describe when evaluating duplication, even with the branch scope mode enabled.

My config looks like this:

 "jasmine/expect-matcher": 2,
 "jasmine/missing-expect": 0,
 "jasmine/new-line-between-declarations": 0,
 "jasmine/new-line-before-expect": 0,
 "jasmine/no-spec-dupes": [1, "branch"],
 "jasmine/no-suite-dupes": [1, "branch"],
 "jasmine/prefer-toHaveBeenCalledWith": 0

My describe blocks follow this general shape:

    describe(`${ACTIONS.DATA_LOADING}`, () => {
        it('should set isLoading', () => {
            action = {
                type: ACTIONS.DATA_LOADING
            };
            result = {
                isLoading: true
            };

            Reducer(reducer).withState(state).expect(action).toReturnState(result);
        });
    });

    describe(`${ACTIONS.DATA_SAVING}`, () => {
        it('should set isLoading', () => {
            action = {
                type: ACTIONS.DATA_SAVING
            };
            result = {
                isLoading: true
            };

            Reducer(reducer).withState(state).expect(action).toReturnState(result);
        });
    });

karma/jasmine execute the tests normally and emit the correct spec titles in the output, however the eslint output yields the following warnings:

Duplicate spec: "should set isLoading" jasmine/no-spec-dupes
Duplicate spec: "should set isLoading" jasmine/no-spec-dupes

I am using
node.js v8.11.1
eslint 3.19.0
eslint-plugin-jasmine 2.10.1

Failed to load plugin jasmine

Getting the following error:

ERROR in ./index.js
Module build failed: Error: Failed to load plugin jasmine: Cannot find module 'eslint-plugin-jasmine'
    at Function.Module._resolveFilename (module.js:339:15)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.module.exports.load (/Users/williammartins/proj/password-manager-client/node_modules/eslint/lib/config/plugins.js:116:26)
    at Array.forEach (native)
    at Object.module.exports.loadAll (/Users/williammartins/proj/password-manager-client/node_modules/eslint/lib/config/plugins.js:138:21)
    at Object.load (/Users/williammartins/proj/password-manager-client/node_modules/eslint/lib/config/config-file.js:443:21)
    at loadConfig (/Users/williammartins/proj/password-manager-client/node_modules/eslint/lib/config.js:67:33)
    at getLocalConfig (/Users/williammartins/proj/password-manager-client/node_modules/eslint/lib/config.js:129:23)

In my package.json:

    "eslint": "2.3.0",
    "eslint-loader": "1.3.0",
    "eslint-plugin-jasmine": "1.6.0",
    "eslint-plugin-react": "4.2.0",
    "eslint-plugin-sort-class-members": "1.0.0",
    "estraverse-fb": "1.3.1",
    "jasmine": "2.4.1",
    "jasmine-core": "2.4.1",

In my .eslintrc:

  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:jasmine/recommended"
  ],
  "parser": "babel-eslint",
  "plugins": [
    "sort-class-members",
    "react",
    "jasmine"
  ],

Detecting describe(function (done) { ... })

I originally reported an issue in Jasmine: jasmine/jasmine#896 but now I think it would be actually more appropiate here.

I spent half an hour debugging this.

describe('stuff', function (done) {
    it('works good', function () {
        myHttp.get(url).then(function (response) {
            expect(response.data.length).toBeGreaterThan(10000);
        }).then(done, fail);
    });
});

I got an error in some other unrelated test, with no stacktrace (because async), and had to fire up a debugger to understand what's happening. And it was just a simple mistake.

(In case you still didn't notice: I put done in describe instead of it.)

I believe this wouldn't be hard to do (as you already look at the arguments of the function given in it) and would save other programmers from mistakes like this.

Tests fail

I would like to add a new rule which enforces to make an expectation in an it block.

However, an existing test failed after cloning the repository and running npm install and npm test.

$ npm test

> eslint-plugin-jasmine@ pretest /home/remco/git/eslint-plugin-jasmine
> eslint index.js lib test


> eslint-plugin-jasmine@ test /home/remco/git/eslint-plugin-jasmine
> mocha



  no-disabled-tests
    1) describe("", function() {})

  no-focused-tests

  no-spec-dupes

  no-suite-dupes


  0 passing (7ms)
  1 failing

  1) no-disabled-tests describe("", function() {}):
     TypeError: Cannot read property 'getRuleOptionsSchema' of undefined




npm ERR! Test failed.  See above for more details.

Newline before expect is opt-out

Do you want to request a feature or report a bug?
Not sure, bug maybe?

What is the current behavior?
Newline before expect is opt-out

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
Newline before expect is opt-in

Please mention your node.js, eslint-plugin-jasmine and operating system version.
node: 7.9.0
eslint-plugin-jasmine: Used to be ^2.2.0, now locked to 2.2.0
osx: 10.11.6

My team uses the jasmine plugin and we suddenly noticed that eslint --fix was touching every Spec file in each project and adding newlines. Our specs tend to look something like this: http://i.imgur.com/bv9y2rM.png So now they're filled with whitespace.

Can this rule be made opt-in instead of opt-out?

no-suite-callback-args does not work with ES6 arrow function

the following gives an error:

describe("A suite", function(done) {});
but the same with an arrow function does not always report an error:

describe("A suite", (done) => {});

.eslintrc.json file:

{
    "env": {
        "es6": true,
        "node": true,
        "browser": true,
        "jasmine": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        "plugin:jasmine/recommended"
    ],
    "installedESLint": true,
    "parserOptions": {
        "ecmaVersion": 6,
        "ecmaFeatures": {
            "jsx": true
        },
        "sourceType": "module"
    },
    "plugins": [
        "react", "jasmine"
    ]
}

Add no-spec-dupes rule

Following #7, we should add a rule that checks for duplicate specs (it blocks).

The guts of no-suite-dupes should be extracted out into lib for reuse here.

Rule suggestion: no-global-setup

This rule would enforce that no beforeEach, afterEach, beforeAll, or AfterAll are defined outside a describe.

For example:
Invalid:

beforeEach(function() {
  //Code goes here...
});
describe(function() {
});

valid:

describe(function() {
  beforeEach(function) {
    //Code goes here...
  });
});

Feature Request: Break jasmine/valid-expect into separate rules

We would like to suppress only some warnings for this rule.

E.g. we use
(1) dynamically evaluated expect and
(2) custom messaging with expect(..., "custom message").to.equal(...)
However the other warnings are still valid for us.

By breaking the rule into separate rules we would obtain the desired fine control over the warnings.

expect() with no actual expectations

The problem and a custom eslint rule implementation can be found here: http://stackoverflow.com/questions/33470377/expect-with-no-actual-expectations.

To summarize, do you think we can add a new jasmine eslint rule that would catch:

• more than 1 argument passed to expect()
• there was nothing called on expect()

Example violations:

expect(page.filters.fromDateLabel.getText(), "After");
expect("After");
expect();

Please let me know if it makes sense to make this rule a part of eslint-plugin-jasmine and I'll prepare a PR. Thanks!

prefer-jasmine-matcher rule bug

Do you want to request a feature or report a bug?

bug

What is the current behavior?

Linter throws an error for expect call expression with no arguments.

TypeError: Cannot read property 'type' of undefined
    at Linter.CallExpression (C:\projects\NG\node_modules\eslint-plugin-jasmine\lib\rules\prefer-jasmine-matcher.js:20:23)
    at emitOne (events.js:101:20)
    at Linter.emit (events.js:188:7)
    at NodeEventGenerator.applySelector (C:\projects\NG\node_modules\eslint\lib\util\node-event-generator.js:265:26)
    at NodeEventGenerator.applySelectors (C:\projects\NG\node_modules\eslint\lib\util\node-event-generator.js:294:22)
    at NodeEventGenerator.enterNode (C:\projects\NG\node_modules\eslint\lib\util\node-event-generator.js:308:14)
    at CodePathAnalyzer.enterNode (C:\projects\NG\node_modules\eslint\lib\code-path-analysis\code-path-analyzer.js:602:23)
    at Traverser.enter (C:\projects\NG\node_modules\eslint\lib\linter.js:922:36)
    at Traverser.__execute (C:\projects\NG\node_modules\estraverse\estraverse.js:397:31)
    at Traverser.traverse (C:\projects\NG\node_modules\estraverse\estraverse.js:501:28)

If the current behavior is a bug, please provide the steps to reproduce.

Write any spec with expect(); and make it run through eslint

import Foo from "foo";

describe("foo", function () {
    it("is defined", function () {
        expect();
    });
});

What is the expected behavior?

No error, the call expression should be ignored or reported as an error such as no-empty-expect.

Please mention your node.js, eslint-plugin-jasmine and operating system version.

node 8

eslint-plugin-jasmine 2.7.1

ubuntu 16.04

I'll be happy to fix this next week, but maybe someone can pick it up sooner :)

no-spec-dupes fails if 2 specs have the same name in 2 different describes in same file

describe('foo1', () => {
	it('bar', () => { });
});
describe('foo2', () => {
	it('bar', () => { });
});

Actual: no-spec-dupes is triggered
Expected: no-spec-dupes should not be triggered

eslint-plugin-jasmine version: 2.2.0