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

FR: a button to generate the snapshots for a single test before tests fail #191

Open
gregveres opened this issue May 14, 2020 · 1 comment

Comments

@gregveres
Copy link
Contributor

Is this a bug report or a feature request?

This is a feature request.

Version Info

  • Version of Majestic: 1.7.0
  • Version of Jest: 25.3
  • Version of Node:
  • Operating System:

Reproduction Repo

I would like to repurpose the <> button on a unit test page. I would like to replace that button with a camera icon that, when clicked, would run jest -u so that jest will create / update the snapshots for just that file and that it would do it without having to wait for the tests to run and fail.

I know that some people might like the <> button today, but there is no reason that this should be a button. The function of the <> button (loading the test file in VSCode) could be moved to clicking on the file name and to indicate that it is a link, the "open page in other window icon" can be added to the end of the file name.

The benefit of this would be that it would stream line the test development process because when I know that the snapshots need to be regenerated, I could regenerate them manually without having to wait for the failed snapshot match.

@gregveres
Copy link
Contributor Author

Looking at the code, I think all that needs to happen is that the condition for displaying the update snapshot button should be removed. This would display the snapshot button all the time, which I believe is an improvement.

Ideally it would be great if we knew that there were snapshots in the file and if that was the case, then display the button. But if we can't know that there are snapshots in the file, then I, for one, would prefer to have the button visible all the time.

gregveres pushed a commit to gregveres/majestic that referenced this issue May 14, 2020
I feel that it is more important to have the ability to
always update the snapshot at any time than it is to
only display the snapshot button when there is a failing
snapshot test. This change removes the condition
around displaying the snapshot button so that the
button is always visible

Raathigesh#191
gregveres pushed a commit to gregveres/majestic that referenced this issue May 15, 2020
This commit implements issue Raathigesh#186. I can't know if there is a snapshot
for each but I can add a button to the summary that opens the snapshot
for the file in the code editor. That's what this commit does. It adds
the button to the UI and a mutation to send to the server to open the
snapshot in the editor.
And it implements issue Raathigesh#191. There was already a button for generating
a snapshot, but it was only visible when there was a detected snapshot
error. This caused us to have to run known failing tests before we could
get the button to generate the snapshots. Now the button is there all
the time, so if you know your snapshots are out of date, then you can
generate them immediately and save time.
Raathigesh pushed a commit that referenced this issue May 21, 2020
This commit implements issue #186. I can't know if there is a snapshot
for each but I can add a button to the summary that opens the snapshot
for the file in the code editor. That's what this commit does. It adds
the button to the UI and a mutation to send to the server to open the
snapshot in the editor.
And it implements issue #191. There was already a button for generating
a snapshot, but it was only visible when there was a detected snapshot
error. This caused us to have to run known failing tests before we could
get the button to generate the snapshots. Now the button is there all
the time, so if you know your snapshots are out of date, then you can
generate them immediately and save time.

Co-authored-by: Greg Veres <greg.veres@rogers.com>
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

No branches or pull requests

1 participant