I didn't know snapshot testing was a thing

My Angular course: angularstart.com/
I kept coming across the "toMatchSnapshot" matcher when working with Jest tests. This was a method I wasn't used to testing with so I decided to dig into it and find out how it works, and it's pretty great.
Source code: github.com/nartc/ngxtension-p...
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Want to build mobile apps with Angular?: ionicstart.com
0:00 Introduction
0:56 Using snapshot tests
1:49 TDD with snapshot testing
#angular #jest #testing
- More tutorials: modernangular.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

I have a newsletter if you want to join: mobirony.ck.page/4a331b9076

[@sakesun]

Magical audio is one of the secret recipe of this channel content.

[@123456crapface]

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

[@FlyingPenguino]

Consider making a video about screenshot testing 😊

[@jeffnikelson5824]

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.

[@Dajuhf]

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.

[@havokgames8297]

You should be catching this in code review if so.

[@PaulSebastianM]

​@@havokgames8297ha ha yeah right.

[@havokgames8297]

Neither did I. Great overview thanks.

[@dafemele10]

Sorry for spamming, i wanna ask again, what font are you using?

[@JoshuaMorony]

It's MesloLGS NF

[@hollowbug2443]

Oh my god, I can understand snapshotting UI Elements for regression testing but snapshotting the code itself, what is this madness?! 😂

[@JoshuaMorony]

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

[@hollowbug2443]

@@JoshuaMorony ah, okay - I didn't get that information when I skimmed through the vid, makes more sense now

[@FlyingPenguino]

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)

[@JoshuaMorony]

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

[@001HK0]

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.

[@JoshuaMorony]

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

[@001HK0]

@@JoshuaMorony Yes, that makes sense.

[@adambickford8720]

You should be testing what you want, not what you did. Conceptually, this feels backwards.

[@johalternate]

In this case, the snapshot is exactly what you want.

[@brandongregori995]

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.

[@JoshuaMorony]

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.