Skip to content
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

Interpret null Describe TestName to mean value can't be eval'd #1701

Merged

Conversation

rkeithhill
Copy link
Contributor

PR Summary

PSES will now return a null for describeBlockName to mean that this is a valid Pester Describe block but we couldn't evaluate the test name. This will cause the extension to pop a dialog indicating this and giving the user the chance to debug or run all the tests in the file.

Two things to consider: 1) the text of the message in the dialog box and 2) should this be an error box (as it is now) or a warning box?

PR Checklist

Note: Tick the boxes below that apply to this pull request by putting an x between the square brackets.
Please mark anything not applicable to this PR NA.

  • PR has a meaningful title
  • Summarized changes
  • PR has tests
  • This PR is ready to merge and is not work in progress
    • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready

@rkeithhill
Copy link
Contributor Author

This is the dialog that pops in this case:

image

Copy link
Contributor

@rjmholt rjmholt left a comment

Choose a reason for hiding this comment

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

This is really nice! Thanks @rkeithhill!

@@ -18,12 +18,12 @@ export class PesterTestsFeature implements IFeature {
this.command = vscode.commands.registerCommand(
"PowerShell.RunPesterTestsFromFile",
() => {
this.launchTests(vscode.window.activeTextEditor.document.uri, false);
this.launchTests(vscode.window.activeTextEditor.document.uri, false, undefined);
Copy link
Contributor

Choose a reason for hiding this comment

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

The true, undefined and false, undefined are starting to look a bit hairy to my mind (i.e. in C# I'd look to use named parameters). Is there a way we could be more explicit about these parameters, like using TypeScript optional parameters or similar? More a question than a veiled suggestion.

Copy link
Contributor Author

@rkeithhill rkeithhill Jan 17, 2019

Choose a reason for hiding this comment

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

Yeah, the same thought crossed my mind as I was coding it up. It can obviously be made to work but feels brittle. I think we could handle this better - perhaps have a fourth parameter to the launch function which indicates the desire is to debug/run the whole file. Let me take a crack at this tonight.


if (answer === "Yes") {
describeBlockName = undefined;
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Personally I would make this:

if (answer === "No") {
    return;
}

describeBlockName = undefined;

but I recognise it's a style preference as much as anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that is cleaner. :-) I'll make the change.

@rkeithhill
Copy link
Contributor Author

@rjmholt @SydneyhSmith Any thoughts on the text in the dialog above and whether it should be an error dialog? Good enough?

Copy link
Member

@TylerLeonhardt TylerLeonhardt left a comment

Choose a reason for hiding this comment

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

This looks great @rkeithhill!

@rjmholt
Copy link
Contributor

rjmholt commented Jan 18, 2019

@rjmholt @SydneyhSmith Any thoughts on the text in the dialog above and whether it should be an error dialog? Good enough?

I think the dialog is perfect

@rjmholt rjmholt merged commit 6bda814 into master Jan 18, 2019
@rkeithhill rkeithhill deleted the rkeithhill/fix-pses-827-pester-testname-expandable-str branch January 18, 2019 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants