I saw this video yesterday and started incorporating snapshotTesting for this query parser I am writing in js. it consumes and returns massive jsons and before i was printing the result and copy pasting that into my code and modifying as needed. this is so much cleaner and easier. I was able to iterate 3-5 times faster in this specific case. thank you sir
I totally see the benefit in checking json data but updating the snapshot of a template in a tdd cycle before I actually to the changes to the template feels somewhat awkward.
Seems interesting but, idk, seems that some team member would only update the snapshot (for purpose or only mistakenly) and the tests that should be fine now have a error that seems a hell to fix if you're not part of the situation.
I personally don't like snapshot testing like this because the intent of such test could be lost (what business cases you're checking). Also doesn't it violate the "don't test the internals" guideline of TDD? I mean, everytime you change the source code, you'll have to update the snapshot too. I guess it's all about what kind of problems you want to avoid during development cycle of the product. But yeah, if you really want to store snapshots of your code - - you're already doing that with Git (kinda)
To be clear, the snapshot is of a static example template defined within the test itself, it's not testing the source code of an application it is testing how one (or a few) particular example template strings are transformed. So the tests will keep passing and the snapshots won't need to be updated as long as the schematic keeps doing what it is supposed to be doing - the implementation of the schematic could even be changed without the snapshot being updated as long as the behaviour of the schematic remains unchanged
It's snapshotting the result of a transformation on a string that just happens to be code - we expect that if we pass this function a string representing code, it will transform that string to modify that code in a particular way
I worry that this could make writing a lot of fragile tests that don't get at the underlying functionality more appealing because of how easy it is to ignore them every release by --updateSnapshot'ing every time. Obviously "good devs" won't do this on purpose, but it could happen unintentionally with some meager justification.
You will be able to see the diff for the snapshot file when reviewing the PR though, and unless reviewers just aren't paying attention (which is its own problem) it should be caught if a dev were trying to "cheat" the test - but yes it would be possible for something to slip by, but I think this is more of a dev problem then a problem with the approach in general
If I'm understanding it correctly, the snapshot is the output of whatever you are testing. So you can do a snapshot of a function return, or of your component UI. The latter imo makes the most sense, because I can see that the UI looks good after some change is made, and I just want that state to be remembered and tested against so I don't need to write a whole bunch of tedious tests.
This still feels like "testing what you want" to me. If we take this example back to the beginning, before any code has been implemented yet, I create a snapshot of the result of the "readContent" function which will output nothing or just return the string unchanged. I edit the result of the snapshot to what I want it to be, and then get to work on making the function output the correct result. Alternatively, with less of a TDD approach, you make the transform work how you want up front, then take the snapshot to ensure the transformations you are supporting aren't broken in the future. This is still very valid and useful imo.
