Hacker News new | ask | show | jobs
by Hasu 533 days ago
I'm not sure you understand what snapshot testing is. It's a form of testing where you render frontend components and take a "snapshot", storing the output and saving it for later, then on the next test run, the component is rendered again and compared to the saved snapshot.

Any change that modifies the rendering of any component under test will break snapshot tests. It's literally just a test that says, "Is this render function still the same as it used to be?"
1 comments
yawaramin 532 days ago
I'm not sure you understand how to capture snapshots at the correct level of granularity. If you have snapshots that are breaking for irrelevant changes, then by definition those changes don't need to be snapshotted, do they? Cut down the snapshot to only the relevant part of the rendered HTML so that when it fails, you know something broke.

Eg in htmx we can add a snapshot test for the pagination component I mentioned in this comment: https://news.ycombinator.com/item?id=42619553

This snapshot will break if I have a bug in my pagination logic implementation, and it's highly unlikely to fail for random irrelevant changes.

link
Hasu 532 days ago
It would still break if you need to modify that output in any way. Need to add a class for styling? The snapshot breaks. Need to add a new hx-attribute? The snapshot breaks. It's not tied to the logic, it's tied to whatever markup you output. You've reduced the surface area of the problem, but not eliminated it.

> If you have snapshots that are breaking for irrelevant changes, then by definition those changes don't need to be snapshotted, do they?

You're so close to getting it.

link
yawaramin 532 days ago
> Need to add a class for styling?

How often? All the time? Or relatively rarely? For most projects, it's the latter. We are not constantly churning the styling.

> Need to add a new hx-attribute? The snapshot breaks. It's not tied to the logic

An `hx-` attribute is logic. That's the point of htmx.

> You've reduced the surface area of the problem, but not eliminated it.

That's a risk of any kind of unit test. You can always have false positives.

> You're so close to getting it.

That tests should be fixed until they're robust? I'm not a fan of the learned helplessness of the 'We couldn't figure out how to do XYZ, therefore XYZ is a bad idea' approach.

link