-
Notifications
You must be signed in to change notification settings - Fork 200
Converted open rule tests from c* to no-* #665
Converted open rule tests from c* to no-* #665
Conversation
Continues #489.
Ugh CRLF... trying to fix up one discrepancy... |
@IllusionMH I'll leave this open in case you want to review, then merge it in if you don't get a chance or in the next week. :) |
@JoshuaKGoldberg sorry for delay, I will return to reviewing this PR later today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some duplicate blocks and folders. And looks like 1 valid case is missing in (at least I wasn't able to find it).
Will continue review tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found few tests that are in initial files, but not in new (however, some of them are debatable and can be skipped).
At this point I think I've finished review.
Thanks for the thorough review @IllusionMH! I believe I've addressed all your points. No rush on re-reviewing 😊 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most fixes for first review comments are in place, however few problems are still present.
Also found some problems that I've missed during initial review 😞
Also discovered few implementation problems. Will create follow up issues for them.
const FAILURE_STRING_COMPARE_FALSE: string = | ||
BASE_ERROR + 'Move the strict inequality comparison from the expect call into the assertion value. '; | ||
BASE_ERROR + 'Move the strict inequality comparison from the expect call into the assertion value'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: dot was added to previous error message, but removed from this one. Nice to have them consistent.
TestHelper.assertViolations(ruleName, script, []); | ||
}); | ||
|
||
it('should pass on correctly private static methods', (): void => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private static
tests are missing from function-name/default/test.ts.lint
TestHelper.assertViolations(ruleName, script, []); | ||
}); | ||
|
||
it('should pass on correctly protected static methods', (): void => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
protected static
tests are missing from function-name/default/test.ts.lint
@@ -0,0 +1,5 @@ | |||
{ | |||
"rules": { | |||
"function-name": [true, "validate-private-statics-as-static"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like string options like "validate-private-statics-as-static"
are only checked as second option (where first one is object with RegExps).
Source and test that passes 'true'
in place of object (first option) and 'validate-private-statics-as-static'
as second option.
Should be
"function-name": [true, "validate-private-statics-as-static"] | |
"function-name": [true, {}, "validate-private-statics-as-static"] |
And validate-private-statics-as-static/test.ts.lint
is supposed to check that private static
are valid when they are upper case. No errors in both test blocks.
Same problem with options position in validate-private-statics-as-private/tslint.json
and validate-private-statics-as-either/tslint.json
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably related to #661
@@ -0,0 +1,5 @@ | |||
{ | |||
"rules": { | |||
"function-name": [true, "validate-private-statics-as-private"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As described for validate-private-statics-as-static
string param should be in second option position.
"function-name": [true, "validate-private-statics-as-private"] | |
"function-name": [true, {}, "validate-private-statics-as-private"] |
@@ -0,0 +1,18 @@ | |||
var pattern1 = /\\x20/; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All regular expressions (except in string literals) should have single \
before x
. Otherwise it is just escaped back-slash
var pattern1 = /\\x00/; | ||
~~~~~~~ [0] | ||
var pattern2 = new RegExp("\\x00"); | ||
var pattern3 = RegExp("\\x00"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 2 lines should have errors too according to old tests.
On the second thought - it is an issue with implementation based on forgot escapes for \
in strings that contain strings that should have escapes for \
(and we must go deeper 😂 ) in "string-based" Mocha tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #785 for further discussion
@@ -0,0 +1,5 @@ | |||
{ | |||
"rules": { | |||
"no-suspicious-comment": [true, ["https://example.com/*"]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like RegExps shouldn't be additionally wrapped in array.
In original test all passed options are just array of strings
UPD. Looks like in this case it relies on ['123'].toString() === '123'
, but will fail if 2 or more strings passed
|
||
it(`should fail on lower case ${suspiciousWord} comments with colons`, (): void => { | ||
const script: string = ` | ||
// ${suspiciousWord}: you should fix this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like there were no actual tests for lowercase suspicious words 😂, because .toLowerCase()
was missing.
It will be tested by case with link, but for consistency (with initial intent) simple case can be added too.
import { Utils } from '../utils/Utils'; | ||
import { TestHelper } from './TestHelper'; | ||
|
||
describe('noUnsupportedBrowserCodeRule', (): void => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't find new tests for this rule
Thanks for the ping - as we discussed, I'm going to close this one and open many smaller PRs for both of our sanities. For not the first time, lesson learned: giant PRs are almost never a good idea! |
PR checklist
Overview of change:
Excluding @IllusionMH's 🏃 rules, converts list items mentioned starting from
chai-*
throughno-*
rules.