-
-
Notifications
You must be signed in to change notification settings - Fork 58
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
bacon test
with something like insta
can endlessly trigger re-runs
#138
Comments
If your project sources are controlled with git, you shouldn't have any problem: Are you using another source version control system than git ? |
No, but the snapshots should not be ignored. The snapshot files are the source of truth for snapshot tests. You can essentially think of their contents as the |
I guess I could setup git to ignore the pending snapshots, but I kind of rely on pending snapshots to show up in I can't recall a project that uses insta and ignores pending snapshots, but I also don't make a habit of checking Edit: I'll go ahead and give it a try :) I'll re-open if I end up running into any issues with the different workflow |
I wasn't asking you to close the issue, you can keep it open until everybody thinks it's OK. |
I occasionally get this as well, even though my pending snapshot files are under .gitignore for some reason. |
One approach that works well — we use it in PRQL — is to add It comes with the downside of potentially being a bit less clear for new contributors who aren't used to insta, but it's worked fine on net. |
insta
will create a new snapshot file when a snapshot test fails that is used for the next run ofcargo insta review
.insta
creating this file on failure does mean thatbacon test
can get stuck in a loop of:bacon test
runs the test suiteFor possible solutions I was thinking either allowing for excluding files from the file watcher by glob, or allowing for a debouncing period. I'm personally leaning towards the former since having to deal with a debouncing period would be annoying for my workflow when dealing with projects that have longer compile/test times
I'd be willing to make a PR if you think that this would be a worthwhile addition
The text was updated successfully, but these errors were encountered: