[KE-345] Tests (and further fixes) for handling different line endings #139
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…l refactorings in related classes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before the 1.3.50 release I've realised that some of intentions and refactorings are producing incorrect results when run on files with
\r\nline endings. They were transforming correct code into not compiling one. The most important cases were fixed before 1.3.50 release.The goal of this pr is to provide automated way to see if actions are presenting consistent bahavior regardless of line endings in the processed file. To achieve this goal, the custom runner was added that is running every marked test class on files with both
\nand\r\nline endings. This way of doing it in junit 4 is well supported by both eclipse and teamcity. The first commit of this pr additionaly contains fixes to offset calculation issues that were related to endline bugs.At the moment still there is difference in bahaviour for different line endings in 5 test cases, but the files with Windows line endings are still processed in such a way that correct code is generated, the only differences being in formatting and caret position. That test cases are now muted as it is not as important issue as other. Muting them is not a problem, becasue
\nvariants of these tests are still being runned.