Currently you cannot update snapshots without re-running tests. This is problematic because:
Steps to reproduce the behavior:
Update the failed snapshot on disk without re-running the test.
Thanks for opening the issue. While it clearly takes time, I disagree that it is unnecessary or unsafe.
In fact, code alteration in the meantime is exactly why your proposal could be considered unsafe - it updates based on an old state, not the state when pressing u / running jest -u.
It could be debated which behavior is better here, but it's definitely not a _bug_.
@jeysal It should use the state that is shown in the terminal before pressing u and not the unseen state afterwards.
I understand your request, that is what you said in the OP, but it is a feature request and not a bug and it has to be considered as such, not as something we should change without a doubt.
@SimenB @thymikee aside from the refactors needed for storing the serialized Received strings somewhere and being able to write them into the correct files later on, do you think this would be desirable?
@jeysal For me the current behavior is unsafe. I am using jest to test a service that generates videos from requests. I generate a hash from video frames using ffmpeg after each request (https://ffmpeg.org/ffmpeg-formats.html#hash-1) for each video and store the hash in the snapshot. Generating videos takes a long time (even at low resolution and fps). There are many test cases. The hash does not actually tell me anything about the contents of the video so I need to review the video contents manually by opening the file in the output folder before submitting the new hash to the snapshot using interactive mode.
In case the request queue was not cleaned correctly in the MQ server OR in case there is an orphaned process running an older version of the code in parallel I can actually add the hash of an entirely different video to the snapshot. Of course I could review the video twice but this is would be unnecessary if jest allows saving the snapshot displayed in the terminal without re-running the test.
This can be a configuration option.
I wonder if it makes sense to always _always_ update with data from the previous run (like requested here), but still run the tests - that way we know that the data is stable. Right now you can snapshot Math.random() and a -u run will happily update the snapshot and call your test passing, even though a second run would fail. Updating snapshots and then rerunning the tests should not be an observable change (I think?).
A way of opting out of the verification run would then make sense to me, if you do not want that security.
@SimenB I think that it's a good idea especially if there is a way of opting out of the verification run.
Most helpful comment
I wonder if it makes sense to always _always_ update with data from the previous run (like requested here), but still run the tests - that way we know that the data is stable. Right now you can snapshot
Math.random()and a-urun will happily update the snapshot and call your test passing, even though a second run would fail. Updating snapshots and then rerunning the tests should not be an observable change (I think?).A way of opting out of the verification run would then make sense to me, if you do not want that security.