Snapshot testing is a good tactic for adding tests to existing (typically legacy) code. Especially if you’re about to refactor some confusing code where you know it works, but how it works is obfuscated.
You can exercise the current behavior, get a snapshot of the results, then refactor the code to make it clean and clear. You know it still does the same thing because of the snapshot.
You’ll learn more about what the code does during this progress so you can now write informed tests.
Re "inspiring": You could make the first implementation return a hard-coded value that you snapshot instead of letting the final implementation generate the first snapshot.
It would even let you test-drive the implementation, though I guess it sort of defeats the point of snapshot-testing unless the framework somehow improves the error reporting.
In opposition to Snapshot testing, partial matching makes tests less writable, but:
- more Inspiring: "Oh! This test doesn't care about id generation and 'created_at' field etc... you just want to make sure the right 'recipe' is there!"
- more Readable: "Cool! I don't have to play 'where is Waldo' and guess what went wrong."
- more Specific: "I don't care about that 'etag' caching field in this test"
Your general observations on Inspiring, Readable & Specific already hint for this kind of examples, right?
Working with Snapshot tests I had issues when building changes, so it is human imperceptible but as pixel level it was not 100%.
What do you think about use Vision algorithms to check if the storage png is visual the same?
I tested it and worked perfect because if you add different pixel color, it will be consider different, but if it is a gradient small change variation, it could consider it ok! What do you think?
I am asking because it could variate conform the developer local apps versions for example.
The "snapshots" referred to in Snapshot Testing are not pixels (which I have also used, with similar frustrations), but object structures (or even just primitives).
When it fails, replace the 9999 with the real answer. 9999 is easy to type, and easy to double click, and select with a mouse. And you know it means something that needs replacing.
Am familiar. When I teach TDD I smack peoples' hands when they do this. Some (how much?) of the value of testing first is forcing yourself to think through the scenario in two independent ways. If they match, you have confidence.
It’s the regression thing. If the answer used to be 3 and 3 was right and you still get 3 you know that may least that hasn’t changed. Typically you need a flying flock of such tests to give you some confidence; at least they’re easy to create. (And typically they’re best on more complicated responses.)
Certainly an arrow in the quiver. (I should probably not use archery metaphors, but there we are.)
Snapshot testing is a good tactic for adding tests to existing (typically legacy) code. Especially if you’re about to refactor some confusing code where you know it works, but how it works is obfuscated.
You can exercise the current behavior, get a snapshot of the results, then refactor the code to make it clean and clear. You know it still does the same thing because of the snapshot.
You’ll learn more about what the code does during this progress so you can now write informed tests.
This sounds a lot like approval testing too me. Are they the same? If not, what is the difference?
Snapshot testing could be at any scale.
The "inspiring" part reminds me of Pyret "because" clause. Overall whole language has many interesting choices.
https://pyret.org/docs/latest/testing.html#%28part._.Reasons_for_tests__because_clauses%29
Interesting! I hadn't seen that before.
Re "inspiring": You could make the first implementation return a hard-coded value that you snapshot instead of letting the final implementation generate the first snapshot.
It would even let you test-drive the implementation, though I guess it sort of defeats the point of snapshot-testing unless the framework somehow improves the error reporting.
Totally agreed, but!
...they get as much high marks at Behavioral, Automated & Writable as they get low marks at Inspiring, Readable, Specific.
My typical example is snapshot testing vs. partial matching (e.g. jest / vitest):
`expect(results).toEqual(expect.objectContaining({name: 'babaganoush'}))` (https://jestjs.io/docs/expect#expectobjectcontainingobject)
In opposition to Snapshot testing, partial matching makes tests less writable, but:
- more Inspiring: "Oh! This test doesn't care about id generation and 'created_at' field etc... you just want to make sure the right 'recipe' is there!"
- more Readable: "Cool! I don't have to play 'where is Waldo' and guess what went wrong."
- more Specific: "I don't care about that 'etag' caching field in this test"
Your general observations on Inspiring, Readable & Specific already hint for this kind of examples, right?
I’d like folks to explore all these trade offs. It’s a big space and we’ve hardly touched it so far.
Working with Snapshot tests I had issues when building changes, so it is human imperceptible but as pixel level it was not 100%.
What do you think about use Vision algorithms to check if the storage png is visual the same?
I tested it and worked perfect because if you add different pixel color, it will be consider different, but if it is a gradient small change variation, it could consider it ok! What do you think?
I am asking because it could variate conform the developer local apps versions for example.
The "snapshots" referred to in Snapshot Testing are not pixels (which I have also used, with similar frustrations), but object structures (or even just primitives).
myTest() {
actual = myFunction(3,4);
desired = 9999;
isEqual(actual, desired);
}
When it fails, replace the 9999 with the real answer. 9999 is easy to type, and easy to double click, and select with a mouse. And you know it means something that needs replacing.
Am familiar. When I teach TDD I smack peoples' hands when they do this. Some (how much?) of the value of testing first is forcing yourself to think through the scenario in two independent ways. If they match, you have confidence.
However, these are better than no tests.
It’s the regression thing. If the answer used to be 3 and 3 was right and you still get 3 you know that may least that hasn’t changed. Typically you need a flying flock of such tests to give you some confidence; at least they’re easy to create. (And typically they’re best on more complicated responses.)
Certainly an arrow in the quiver. (I should probably not use archery metaphors, but there we are.)
C'mon. Archery metaphors hit the bullseye.