Better Python tests with inline-snapshot

16 points by a5rocks

msw

One of the reasons I love python is because it’s so powerful and flexible that it’s easy to write this sort of thing yourself. The last time i saw a snapshot testing thread here i was inspired to write my own. Its around 10 lines of python and I’ve been using it ever since.

https://lobste.rs/s/xsquae/my_kind_repl#c_v235bi

zem

This is tedious to write and a pain to maintain. It's also not very thorough - you have no idea what other fields you're silently ignoring.

these are two separate concerns, and I would love to see an enhancement that let me write something like {'a': 1, _: ...} to say "I don't care about the rest of the container, but test and update this subset of it".

ubernostrum

I'm not 100% certain, but you might be able to do something like this with the structural pattern-matching constructs added in Python 3.10.
- Halkcyon
  
  Correct, you can match a subset of dict keys within the case statements; no special "rest" synax needed, either.
- zem
  
  honestly I like the looks of this library enough that if they're open to the feature I might try adding it myself
quasi_qua_quasi

I've done this (not using this library, but with other snapshot libraries) by snapshotting {"a": myObject.a} or similar (with a function to do this if there are multiple cases where I want it).
- zem
  
  does that match if there are extra keys (e.g. I want to match {'a': 1, 'b': 2, 'c': 3} with only the 'a' key specified in the snapshot)
  - quasi_qua_quasi
    
    Yeah, you're just constructing a new object that only contains the parts of the old object you care about snapshotting.
- l0b0
  Neat idea, but I wouldn't use this:
  
  If you have a bunch of tests which assert the same fields, that's a problem. Tests should be orthogonal, and not test the same thing over and over. Using this library would encourage asserting the contents of all the fields all the time. This clutters the test with irrelevant data, making for many more failures than necessary when something changes. This is basically the same problem as snapshot tests.
  
  It encourages sloppy testing: look at the first test which failed, check that some fields changed as expected, treat that as the only thing which changed (because reviewing the diff of dozens of virtually-identical tests is going to be really tedious), then regenerate all the snapshots. Repeat until bugs inevitably sneak in.
- giacomo_cavalieri
  
  Snapshot tests are so underrated! Love them. Though I slightly prefer when they’re not inline but stored in a separate file
- ocramz
  
  Comment removed by author
- pekkavaa
  
  In the first example, why wouldn't you test just the fields you're interested in? Why is it important to include rest of the object contents that get autogenerated anyway?