Skip to content

Force tab size on test run #731

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
merged 16 commits into from
Oct 24, 2022
Merged

Force tab size on test run #731

merged 16 commits into from
Oct 24, 2022

Conversation

Will-Sommers
Copy link
Collaborator

@Will-Sommers Will-Sommers commented Jun 3, 2022

  • This fixes test failures related to different local configurations
  • Tests expect tabSize to be 4

Fixes: #598

Checklist

  • N/A - I have added tests

- This fixes problems related to different local configurations
- Tests expect tabSize to be 4
@Will-Sommers Will-Sommers requested a review from pokey as a code owner June 3, 2022 17:30
@AndreasArvidsson
Copy link
Member

AndreasArvidsson commented Jun 5, 2022

This will only force tab size to be for when re-running the tests. I think we need to add the same to the test recorder otherwise every test will be recorded with the user tab setting, but run with a fixed setting.

@pokey
Copy link
Member

pokey commented Jun 8, 2022

This will only force tab size to be for when re-running the tests. I think we need to add the same to the test recorder otherwise every test will be recorded with the user tab setting, but run with a fixed setting.

I'll second what @AndreasArvidsson says here. I think if we detect that the extension is running in debug mode, we should make the same tabSize change

@Will-Sommers
Copy link
Collaborator Author

Not important, but I'm still a little curious about why this didn't break for me, with other tests that I've recorded.

@pokey — I'll likely add the setting here as well rather than in the actual extension.

https://github.com/cursorless-dev/cursorless/blob/main/src/test/suite/recorded.test.ts#L74-L78

@pokey
Copy link
Member

pokey commented Jun 8, 2022

Not important, but I'm still a little curious about why this didn't break for me, with other tests that I've recorded.

did you record tests that include snippet wrapping? I think those are the ones that will break

@pokey — I'll likely add the setting here as well rather than in the actual extension.

https://github.com/cursorless-dev/cursorless/blob/main/src/test/suite/recorded.test.ts#L74-L78

Sorry not sure I follow—that won't impact recording right?

@Will-Sommers
Copy link
Collaborator Author

did you record tests that include snippet wrapping? I think those are the ones that will break

Nope, you're right. One other indent and fold test broke as well though

Sorry not sure I follow—that won't impact recording right?

Multi-tasking between emails, sorry. You're right.

- Check if we're in debug mode and set tabSize if so
- Move tabSize to constants file
Copy link
Member

@pokey pokey 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 with minor tweak

Comment on lines 64 to 67
if (vscode.window.activeTextEditor) {
vscode.window.activeTextEditor.options.tabSize =
DEFAULT_TAB_SIZE_FOR_TESTS;
}
Copy link
Member

Choose a reason for hiding this comment

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

hmm maybe we should only do this if they're recording a test? Otherwise we'll clobber their tab size if they have cursorless debug mode on

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Heyo @pokey — I moved this entire step into the TestCaseRecorder since we have state there about whether we should or should not set the tabs. That also bring the code out of the CommandRunner loop. We clean up at the end and reset to the original tab setting, if a user stops recording their test.

Copy link
Member

@pokey pokey left a comment

Choose a reason for hiding this comment

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

I think we should do this one in the preCommandHook / errorHook / postCommandHook so that

  1. The code should be simpler, I think, because we don't need to set / unset it in so many places
  2. We can properly handle splits in the future. Your current code will break with multiple splits

I would a keep list of visible editors and their original tab stops in preCommandHook, and reset them on those editors in postCommandHook / errorHook

Does that make sense?

Alternately, you can just do activeTextEditor, if the visible editors thing looks painful. I am considering adding split testing support in #721; debating whether it's worth supporting recording tests this way. So if it looks painful to do all visible editors, active is prob fine, but I still think it's simpler to do it in pre / postCommandHook.

But I don't feel too strongly if you think it's going to be better this way 😊

@AndreasArvidsson
Copy link
Member

@pokey I think you can have a look at this one now

Copy link
Member

@pokey pokey 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 to me! Needed to make some tweaks because the restore code was broken

@pokey pokey merged commit 272dc49 into main Oct 24, 2022
@pokey pokey deleted the wsommers/tests-failing-locally-598 branch October 24, 2022 20:19
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.

Tests failing locally
4 participants