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

Rule proposal: no-skip-without-comment #201

Open
Lakitna opened this issue Jul 16, 2019 · 4 comments
Open

Rule proposal: no-skip-without-comment #201

Lakitna opened this issue Jul 16, 2019 · 4 comments

Comments

@Lakitna
Copy link
Contributor

Lakitna commented Jul 16, 2019

In my team, we made the decision that when a test is skipped for some reason that we add a short comment explaining why. We do this purely for maintenance and organisational reasons.

Doing it like this helps us with:

  • Communication about which skipped tests are linked to which issue and thus when they can be unskipped.
  • Knowing why tests are skipped, even if it's months later.

In reality, this often looks something like:

// SKIP pending #201
it.skip('does a thing', function() {

However, I don't always remember to add these comments. A rule will improve team consistency here.

@lo1tuma
Copy link
Owner

lo1tuma commented Jul 17, 2019

I think this could be an option of the existing rule no-skipped-tests.

@Lakitna
Copy link
Contributor Author

Lakitna commented Jul 17, 2019

It could, but I'd prefer it as a separate rule. I think there is value in making rules have the smallest possible scope.

@lo1tuma
Copy link
Owner

lo1tuma commented Jul 17, 2019

But then we could have a scenario where users enable both rules at the same time, which doesn’t seem to be a useful thing to do.

@Lakitna
Copy link
Contributor Author

Lakitna commented Jul 17, 2019

True, but the worst that can happen is getting a double error.

Besides, there are definitely people, myself included, who simply disable rules they don't like instead of looking at options.

Because of lower willingness to do research regarding these kinds of thing, I think it would be more intuitive to make it a separate rule that does exactly what it says in the name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants