FR: clicking on a test with a snapshot should open the snapshot for viewing #186
Comments
|
I used to use WallabyJS quite a bit, one of the really good features that had was an option to open a snapshot in a side-by-side diff (which makes for much easier comparison) and then update the snapshot from the dialog if the new is correct. |
|
@IPWright83 Yes, that would be a great feature! |
This adds the ability to quickly jump to the error in the source file on a failing test. This fixes issue Raathigesh#186
|
@IPWright83 actually, I am pretty sure it starts flat. When I double checked 2 days ago, I didn't realize that I had overwritten the version I was checking with the unmodified version. I am having trouble building right now, but I will double check that it starts collapsed. The original reason I wanted collapsing in the first place is because i have lots of tests in each file and the list was too long for the screen. I wanted it to start collapsed and only spring up to show errors if there are errors. I am pretty sure I was happy with this type of work flow when I did the PR. My branch also has a fix for #184. When there is a failed test, clicking on the failed test opens that file in VSCode to the failure. I hadn't submitted that change as a PR because the first PR wasn't accepted and the second PR was built on the first. |
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.
One of the other majestic users commented on the issue asking if the state defaulted to closed or open. Thinking it through, it should default to closed but the implementation defaulted to open. So it has now been changed to default to closed unless there is a failing test. Then it springs open to show the failed test. The comments were mentioned in Raathigesh#186 but this change is really for Raathigesh#180
|
@IPWright83 just in case you are still interested in this, I updated my fork to the latest version from the master fork and then continued enhancing it. It turned out that the tests did default to open, but now on my fork they default to closed. If the maintainer takes the collapse code, then I can create PRs for all the other enhancements that I have done. I think at this point it is pretty close to where I want it. There might be a few more things I will do eventually like a collapse/expand all for the project tree and for the test list. |
|
@gregveres honestly I got a little confused by the expand/collapse discussion with relation to snapshots! |
This adds the ability to quickly jump to the error in the source file on a failing test. This fixes issue Raathigesh#186
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.
This adds the ability to quickly jump to the error in the source file on a failing test. This fixes issue #186 Co-authored-by: Greg Veres <greg.veres@rogers.com>
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>
This is a feature request.
I have started doing unit tests for Vue components and I find that I am opening up the snapshot to see the underlying html that I need to run tests against. This makes it much easier to write the unit tests and to know where to put the "data-test" attributes so that I can use them in my tests.
It would be great if Majestic could recognize that a unit test file has an associated snapshot file and provide a way to show me the snapshot related to a particular test.
It isn't as useful to just display the snapshot file because it could be huge and there could be many snapshots in the file. But each snapshot is prefixed with the unit test that created it. So it would be nice if each unit test that had a snapshot had a little "snapshot" icon beside it's name that was a link to an action that would popup a dialog with the contents of the snapshot.
The text was updated successfully, but these errors were encountered: