Skip to content

Improve verify.codeFixAvailable #24325

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
3 commits merged into from
May 22, 2018
Merged

Improve verify.codeFixAvailable #24325

3 commits merged into from
May 22, 2018

Conversation

ghost
Copy link

@ghost ghost commented May 22, 2018

  • Always require the array -- don't just assert that some code fix is available, assert the particular codefixes that are available.
  • Don't need verify.not.codeFixAvailable() as it is equivalent to verify.codeFixAvailable([]);.

@ghost ghost requested review from sheetalkamat and amcasey May 22, 2018 18:00
if (negative) {
if (codeFixes.length) {
this.raiseError(`verifyCodeFixAvailable failed - expected no fixes but found ${codeFixes.map(c => c.description)}.`);
assert.equal(info.length, codeFixes.length);
Copy link
Member

Choose a reason for hiding this comment

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

My experience has been that asserts like this tend to produce unhelpful output when they fail. I haven't found a silver bullet but sometimes I break verification into two steps - the first determines whether or not verification succeeded and the second produces a human-readable representation of the difference between the expected and actual values.
To be more concrete, if you get fewer fixes than expected, I think this will produce a message like "expected 4 but got 3". It would be much more helpful to know which fixes were actually found or, better still, which were missing.

@@ -3,4 +3,4 @@
// @noImplicitAny: true
//// function f(y, z = { p: y[

verify.not.codeFixAvailable();
verify.codeFixAvailable([]);
Copy link
Member

Choose a reason for hiding this comment

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

verify.not appears to be idiomatic in this test framework, so I have no problem leaving it even if it doesn't add expressiveness.

@@ -2997,30 +2997,18 @@ Actual: ${stringify(fullActual)}`);
}
}

public verifyCodeFixAvailable(negative: boolean, info: FourSlashInterface.VerifyCodeFixAvailableOptions[] | undefined) {
public verifyCodeFixAvailable(info: FourSlashInterface.VerifyCodeFixAvailableOptions[]) {
Copy link
Member

Choose a reason for hiding this comment

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

I think you also want to move this to explicit Verify implementation to avoid having it on verify.not
(Move to https://github.com/Microsoft/TypeScript/pull/24325/files#diff-cd92e8371fce86965331cb68f53306f1L4134)

Copy link
Author

@ghost ghost May 22, 2018

Choose a reason for hiding this comment

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

Since @amcasey requested it, I added back verify.not.

@ghost ghost force-pushed the codeFixAvailable branch from afbff9c to 74707a5 Compare May 22, 2018 22:08
this.assertObjectsEqual(fix.commands, info.commands);
});
}
const actuals = codeFixes.map((fix): FourSlashInterface.VerifyCodeFixAvailableOptions => ({ description: fix.description, commands: fix.commands }));
Copy link
Member

Choose a reason for hiding this comment

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

What about change locations?

Copy link
Author

@ghost ghost May 22, 2018

Choose a reason for hiding this comment

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

This method verify.codeFixAvailable just tests for availability -- verify.codeFix will test the actual content of the fix.

@ghost ghost merged commit aed0eb6 into master May 22, 2018
@ghost ghost deleted the codeFixAvailable branch May 22, 2018 23:04
@microsoft microsoft locked and limited conversation to collaborators Jul 31, 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.

2 participants