vim/ale
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
bb08b81bf7
ale/test/handler/test_rubocop_handler.vader

77 lines
3.0 KiB
Plaintext
Raw Normal View History

Fix #760 - Report problems with configuration files for rubocop
2017-07-12 17:41:06 -04:00
Before:
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
runtime ale_linters/ruby/rubocop.vim
Fix #760 - Report problems with configuration files for rubocop
2017-07-12 17:41:06 -04:00
After:
unlet! g:lines
call ale#linter#Reset()
Execute(The rubocop handler should parse lines correctly):
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
AssertEqual
\ [
\ {
\ 'lnum': 83,
\ 'col': 29,
Use rubocop's JSON output format (resolves #339) (#738) * Use rubocop's JSON output format (resolves #339) Rubocop's emacs formatter seems to have changed format in some not-so-ancient version. The JSON formatter should provide a more stable interface than parsing lines with a regex. The JSON formatter was introduced in mid-2013, so it should be safe to assume available in any reasonably-modern environment. The oldest currently-supported version of ruby (according to ruby-lang.org) was not supported by rubocop until 2014. * Rubocop: Use global function for GetType * Rubocop: Use scope prefix in GetType * Rubocop: Update command_callback test * Rubocop: add end_col to Handle
2017-07-09 10:48:04 -04:00
\ 'end_col': 35,
#852 - Capture error codes for Rubocop
2017-11-14 11:50:15 -05:00
\ 'text': 'Prefer single-quoted strings...',
\ 'code': 'Style/SomeCop',
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
\ 'type': 'W',
\ },
\ {
\ 'lnum': 12,
\ 'col': 2,
Use rubocop's JSON output format (resolves #339) (#738) * Use rubocop's JSON output format (resolves #339) Rubocop's emacs formatter seems to have changed format in some not-so-ancient version. The JSON formatter should provide a more stable interface than parsing lines with a regex. The JSON formatter was introduced in mid-2013, so it should be safe to assume available in any reasonably-modern environment. The oldest currently-supported version of ruby (according to ruby-lang.org) was not supported by rubocop until 2014. * Rubocop: Use global function for GetType * Rubocop: Use scope prefix in GetType * Rubocop: Update command_callback test * Rubocop: add end_col to Handle
2017-07-09 10:48:04 -04:00
\ 'end_col': 2,
#852 - Capture error codes for Rubocop
2017-11-14 11:50:15 -05:00
\ 'text': 'Some error',
\ 'code': 'Style/SomeOtherCop',
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
\ 'type': 'E',
\ },
\ {
\ 'lnum': 10,
\ 'col': 5,
Use rubocop's JSON output format (resolves #339) (#738) * Use rubocop's JSON output format (resolves #339) Rubocop's emacs formatter seems to have changed format in some not-so-ancient version. The JSON formatter should provide a more stable interface than parsing lines with a regex. The JSON formatter was introduced in mid-2013, so it should be safe to assume available in any reasonably-modern environment. The oldest currently-supported version of ruby (according to ruby-lang.org) was not supported by rubocop until 2014. * Rubocop: Use global function for GetType * Rubocop: Use scope prefix in GetType * Rubocop: Update command_callback test * Rubocop: add end_col to Handle
2017-07-09 10:48:04 -04:00
\ 'end_col': 12,
#852 - Capture error codes for Rubocop
2017-11-14 11:50:15 -05:00
\ 'text': 'Regular warning',
\ 'code': 'Style/WarningCop',
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
\ 'type': 'W',
\ },
\ {
\ 'lnum': 11,
\ 'col': 1,
Use rubocop's JSON output format (resolves #339) (#738) * Use rubocop's JSON output format (resolves #339) Rubocop's emacs formatter seems to have changed format in some not-so-ancient version. The JSON formatter should provide a more stable interface than parsing lines with a regex. The JSON formatter was introduced in mid-2013, so it should be safe to assume available in any reasonably-modern environment. The oldest currently-supported version of ruby (according to ruby-lang.org) was not supported by rubocop until 2014. * Rubocop: Use global function for GetType * Rubocop: Use scope prefix in GetType * Rubocop: Update command_callback test * Rubocop: add end_col to Handle
2017-07-09 10:48:04 -04:00
\ 'end_col': 1,
#852 - Capture error codes for Rubocop
2017-11-14 11:50:15 -05:00
\ 'text': 'Another error',
\ 'code': 'Style/SpaceBeforeBlockBraces',
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
\ 'type': 'E',
\ },
\ ],
Adds standardrb linter (#2133) See: https://github.com/testdouble/standard StandardRB is to RuboCop what StandardJS is to ESLint. This commit naively copies the RuboCop linter and fixer to point at the standardrb executable. Any other adjustments are very minor (the only I can think of is that standardrb takes a `--fix` option instead of `--auto-correct`). This raises a confusing point to me as both developer and a user: since ale enables all linters by default, won't this run both RuboCop and StandardRB (the results of which will almost always be in conflict with one another)? How does ale already solve for this for the similar case of StandardJS and ESLint?
2018-12-10 16:02:32 -05:00
\ ale#ruby#HandleRubocopOutput(347, [
Use rubocop's JSON output format (resolves #339) (#738) * Use rubocop's JSON output format (resolves #339) Rubocop's emacs formatter seems to have changed format in some not-so-ancient version. The JSON formatter should provide a more stable interface than parsing lines with a regex. The JSON formatter was introduced in mid-2013, so it should be safe to assume available in any reasonably-modern environment. The oldest currently-supported version of ruby (according to ruby-lang.org) was not supported by rubocop until 2014. * Rubocop: Use global function for GetType * Rubocop: Use scope prefix in GetType * Rubocop: Update command_callback test * Rubocop: add end_col to Handle
2017-07-09 10:48:04 -04:00
\ '{"metadata":{"rubocop_version":"0.47.1","ruby_engine":"ruby","ruby_version":"2.1.5","ruby_patchlevel":"273","ruby_platform":"x86_64-linux-gnu"},"files":[{"path":"my_great_file.rb","offenses":[{"severity":"convention","message":"Prefer single-quoted strings...","cop_name":"Style/SomeCop","corrected":false,"location":{"line":83,"column":29,"length":7}},{"severity":"fatal","message":"Some error","cop_name":"Style/SomeOtherCop","corrected":false,"location":{"line":12,"column":2,"length":1}},{"severity":"warning","message":"Regular warning","cop_name":"Style/WarningCop","corrected":false,"location":{"line":10,"column":5,"length":8}},{"severity":"error","message":"Another error","cop_name":"Style/SpaceBeforeBlockBraces","corrected":false,"location":{"line":11,"column":1,"length":1}}]}],"summary":{"offense_count":4,"target_file_count":1,"inspected_file_count":1}}'
Cover the rubocop handler with tests
2017-03-27 14:53:12 -04:00
\ ])
Rubocop: handle empty 'files' array in output The handler previously assumed there would be at least one entry in the 'files' array in the output JSON. It looks like this in the normal case: "files":[{"path":"app/models/image.rb","offenses":[]}] But if RuboCop's config excludes the specified input files, causing no files to be linted, the output is emptier: "files":[] This change causes the handler to treat that case correctly, and also exit early if the reported offense_count is zero.
2017-07-12 19:42:54 -04:00
Execute(The rubocop handler should handle when files are checked and no offenses are found):
AssertEqual
\ [],
Adds standardrb linter (#2133) See: https://github.com/testdouble/standard StandardRB is to RuboCop what StandardJS is to ESLint. This commit naively copies the RuboCop linter and fixer to point at the standardrb executable. Any other adjustments are very minor (the only I can think of is that standardrb takes a `--fix` option instead of `--auto-correct`). This raises a confusing point to me as both developer and a user: since ale enables all linters by default, won't this run both RuboCop and StandardRB (the results of which will almost always be in conflict with one another)? How does ale already solve for this for the similar case of StandardJS and ESLint?
2018-12-10 16:02:32 -05:00
\ ale#ruby#HandleRubocopOutput(347, [
Rubocop: handle empty 'files' array in output The handler previously assumed there would be at least one entry in the 'files' array in the output JSON. It looks like this in the normal case: "files":[{"path":"app/models/image.rb","offenses":[]}] But if RuboCop's config excludes the specified input files, causing no files to be linted, the output is emptier: "files":[] This change causes the handler to treat that case correctly, and also exit early if the reported offense_count is zero.
2017-07-12 19:42:54 -04:00
\ '{"metadata":{"rubocop_version":"0.47.1","ruby_engine":"ruby","ruby_version":"2.1.5","ruby_patchlevel":"273","ruby_platform":"x86_64-linux-gnu"},"files":[{"path":"my_great_file.rb","offenses":[]}],"summary":{"offense_count":0,"target_file_count":1,"inspected_file_count":1}}'
\ ])
Execute(The rubocop handler should handle when no files are checked):
AssertEqual
\ [],
Adds standardrb linter (#2133) See: https://github.com/testdouble/standard StandardRB is to RuboCop what StandardJS is to ESLint. This commit naively copies the RuboCop linter and fixer to point at the standardrb executable. Any other adjustments are very minor (the only I can think of is that standardrb takes a `--fix` option instead of `--auto-correct`). This raises a confusing point to me as both developer and a user: since ale enables all linters by default, won't this run both RuboCop and StandardRB (the results of which will almost always be in conflict with one another)? How does ale already solve for this for the similar case of StandardJS and ESLint?
2018-12-10 16:02:32 -05:00
\ ale#ruby#HandleRubocopOutput(347, [
Rubocop: handle empty 'files' array in output The handler previously assumed there would be at least one entry in the 'files' array in the output JSON. It looks like this in the normal case: "files":[{"path":"app/models/image.rb","offenses":[]}] But if RuboCop's config excludes the specified input files, causing no files to be linted, the output is emptier: "files":[] This change causes the handler to treat that case correctly, and also exit early if the reported offense_count is zero.
2017-07-12 19:42:54 -04:00
\ '{"metadata":{"rubocop_version":"0.47.1","ruby_engine":"ruby","ruby_version":"2.1.5","ruby_patchlevel":"273","ruby_platform":"x86_64-linux-gnu"},"files":[],"summary":{"offense_count":0,"target_file_count":0,"inspected_file_count":0}}'
\ ])
#769 Ignore stderr output and output without JSON we can read for rubocop
2017-07-13 17:47:43 -04:00
Execute(The rubocop handler should handle output without any errors):
Fix #760 - Report problems with configuration files for rubocop
2017-07-12 17:41:06 -04:00
let g:lines = [
\ '{"metadata":{"rubocop_version":"0.48.1","ruby_engine":"ruby","ruby_version":"2.4.1","ruby_patchlevel":"111","ruby_platform":"x86_64-darwin16"},"files":[]}',
\]
AssertEqual
#769 Ignore stderr output and output without JSON we can read for rubocop
2017-07-13 17:47:43 -04:00
\ [],
Adds standardrb linter (#2133) See: https://github.com/testdouble/standard StandardRB is to RuboCop what StandardJS is to ESLint. This commit naively copies the RuboCop linter and fixer to point at the standardrb executable. Any other adjustments are very minor (the only I can think of is that standardrb takes a `--fix` option instead of `--auto-correct`). This raises a confusing point to me as both developer and a user: since ale enables all linters by default, won't this run both RuboCop and StandardRB (the results of which will almost always be in conflict with one another)? How does ale already solve for this for the similar case of StandardJS and ESLint?
2018-12-10 16:02:32 -05:00
\ ale#ruby#HandleRubocopOutput(347, g:lines)
#769 Ignore stderr output and output without JSON we can read for rubocop
2017-07-13 17:47:43 -04:00
\
AssertEqual
\ [],
Adds standardrb linter (#2133) See: https://github.com/testdouble/standard StandardRB is to RuboCop what StandardJS is to ESLint. This commit naively copies the RuboCop linter and fixer to point at the standardrb executable. Any other adjustments are very minor (the only I can think of is that standardrb takes a `--fix` option instead of `--auto-correct`). This raises a confusing point to me as both developer and a user: since ale enables all linters by default, won't this run both RuboCop and StandardRB (the results of which will almost always be in conflict with one another)? How does ale already solve for this for the similar case of StandardJS and ESLint?
2018-12-10 16:02:32 -05:00
\ ale#ruby#HandleRubocopOutput(347, ['{}'])
#769 Ignore stderr output and output without JSON we can read for rubocop
2017-07-13 17:47:43 -04:00
AssertEqual
\ [],
Adds standardrb linter (#2133) See: https://github.com/testdouble/standard StandardRB is to RuboCop what StandardJS is to ESLint. This commit naively copies the RuboCop linter and fixer to point at the standardrb executable. Any other adjustments are very minor (the only I can think of is that standardrb takes a `--fix` option instead of `--auto-correct`). This raises a confusing point to me as both developer and a user: since ale enables all linters by default, won't this run both RuboCop and StandardRB (the results of which will almost always be in conflict with one another)? How does ale already solve for this for the similar case of StandardJS and ESLint?
2018-12-10 16:02:32 -05:00
\ ale#ruby#HandleRubocopOutput(347, [])
Reference in New Issue Copy Permalink