Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Add section about customizing RuleTester (fixes #6227) #6331

Merged
merged 3 commits into from Jun 9, 2016
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/developer-guide/working-with-plugins.md
Expand Up @@ -140,6 +140,11 @@ ruleTester.run("custom-plugin-rule", rule, {
});
```

#### Customizing RuleTester

RuleTester internally uses Mocha's `describe` and `it` methods when available to create tests for each valid and invalid case. If you use another test runner, you can override `RuleTester.describe` and `RuleTester.it` to make RuleTester compatible with it and have proper individual tests and feedback.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would link to https://github.com/jfmengels/eslint-ava-rule-tester as an example on how to do it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super content: says much in few words. Here are a few suggestions about grammar of the first sentence:

  • move to beginning: To create tests for each valid and invalid case,
  • is internally implied in this context?
  • avoid possessive on product name and include its tag line: RuleTester uses describe and it methods from the Mocha test framework when it is available.

Copy link
Contributor Author

@jfmengels jfmengels Jun 8, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Point 1 and 3 sound good.

Not sure I get point 2 though. Are you saying I should leave out the word internally as it may already be implied? I don't think it hurts to make this explicit.

What about @sindresorhus's comment above showing an example? I think having an example is nice, and my package is working well (in "production" in 2 plugins already), but I don't get the feeling that there are a lot of links to external packages that are not in the ESLint org (and thus out of your control?).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if with “internally” reads better to you as an example of audience for this section, keep it.

Your observation about the link agrees with what I have seen.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, I (as a user) would prefer "internally" to be explicit here. But I also like a lot of words to be explicit, possibly more than the average developer. Without "internally", I might assume a stronger dependency link (until I get to "when available" six words later).



## Share Plugins

In order to make your plugin available to the community you have to publish it on npm.
Expand Down