Skip to content

Improve testing of code fixes, and improve diagnostic messages #18742

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

Merged
2 commits merged into from
Sep 26, 2017
Merged

Conversation

ghost
Copy link

@ghost ghost commented Sep 25, 2017

We were reporting fixes to add instance methods as static, and vice versa.
Also added a diagnostic message for adding static properties.
Since this resulted in no test changes, I added functionality to assert the description of code fixes; haven't applied it to every test yet but I think that would be a good idea since we've caught some bugs already.
The new tester no longer ignores whitespace, which uncovered #18741 and #18743 (and also more #18445 errors).

@ghost ghost force-pushed the testCodeFix branch from 153ed52 to cbe0bcd Compare September 25, 2017 15:30
@ghost ghost requested a review from aozgaa September 25, 2017 18:40
Copy link
Contributor

@aozgaa aozgaa left a comment

Choose a reason for hiding this comment

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

Looks good, see comments.

this.applyEdits(change.fileName, change.textChanges, /*isFormattingEdit*/ false);
}

if (this.getRanges().length === 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be easier to understand the tests if we are uniform in requiring a range to be specified, rather than switching the behavior in a way that forces the user to navigate back to this line of the source.

We could alternately come up with a different name for newContent that does capture this switching behavior.

I personally favor the first option, but I'm open to alternatives.

Copy link
Author

Choose a reason for hiding this comment

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

Did the first option.

@@ -2337,6 +2337,38 @@ namespace FourSlash {
}
}

public verifyCodeFix(options: FourSlashInterface.VerifyCodeFixOptions) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider merging this into rangeAfterCodeFix (possibly in a separate PR) to keep the 4/ API simple.

Copy link
Author

Choose a reason for hiding this comment

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

I'm planning to remove all rangeAfterCodeFix in another PR.

@@ -4359,4 +4395,11 @@ namespace FourSlashInterface {
export interface CompletionsAtOptions {
isNewIdentifierLocation?: boolean;
}

export interface VerifyCodeFixOptions {
description: string;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should description and newContent be optional as well?

Copy link
Author

Choose a reason for hiding this comment

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

Not if we want to enforce that these are tested.

@ghost ghost merged commit ecef2dc into master Sep 26, 2017
@ghost ghost deleted the testCodeFix branch September 26, 2017 22:16
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants