Jest: Update snapshots without re-running tests

Created on 18 Feb 2020  路  6Comments  路  Source: facebook/jest

馃悰 Bug Report

Currently you cannot update snapshots without re-running tests. This is problematic because:

  • this takes time (a lot of time in case you have a lot of test cases or the test cases are slow)
  • this is not necessary (jest already know what shapshots failed and what was the value for each snapshot so it can write them immediately instead of re-running tests)
  • this is not safe (re-running the tests does not ensure that the snapshots have not been altered in the meantime: code change, external api change, external db change etc.)

To Reproduce

Steps to reproduce the behavior:

  • use snapshots
  • try to update a snapshots for a failed test without re-running the test

Expected behavior

Update the failed snapshot on disk without re-running the test.

Feature Request

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 -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.

All 6 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StephanBijzitter picture StephanBijzitter  路  3Comments

samzhang111 picture samzhang111  路  3Comments

paularmstrong picture paularmstrong  路  3Comments

hramos picture hramos  路  3Comments

Secretmapper picture Secretmapper  路  3Comments