4 ms·

That honestly sounds like a downside. Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentatio

That honestly sounds like a downside. Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. Having a clear and somewhat stable API (which is a boon for testing) is IMHO a strong reason for the SPA model.

recursivedoubts 2y ago
htmx moves the data -> html transformation to the server side and thus should be more testable
eddd-ddde 2y ago
Not really unstable since you generate it and there's no browser modifying it. However you'd still lack client functionality testing.
seanwilson 2y ago
> Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. For HTML tests, if you target elements by their ARIA role, semantic tag, or by matching against the text/label/title the user would see, it should be robust to a lot of presentation changes (and does some accessibility checks too). It's much more robust than e.g. `body > div > div .card > h2` which are sure to break in tests and slow you down when you make changes later. See Playwright locators for example: https://playwright.dev/docs/locators https://playwright.dev/docs/locators Not sure if this is what you meant, but you can't rely on only the JSON because you can't assume it's been properly transformed into the expected HTML.
yawaramin 2y ago
It's standard practice in the frontend world https://jestjs.io/docs/snapshot-testing https://jestjs.io/docs/snapshot-testing
- sensanaty 2y ago
  In my experience snapshots have largely fallen out of vogue, at least as far as them blocking deploys goes. They're usually flaky, change often, are slow to test and it's way too easy to have false positives which lulls people into complacency and just regenerating the snapshots as soon as they reach a failure. I'm guilty of that myself, unless I can spot the breakage immediately I pretty much just regen the snapshot by default subconsciously because of how often I've had to do that for false positives
  - yawaramin 2y ago
    Then what's to stop you from making any unit test pass by just changing the expectations? The best testing technique in the world can't save us from developer error.
    - Hasu 2y ago
      The problem with snapshot tests is that they tend to fail when something is changed. One property of good tests is that they only fail when something is broken. Snapshot tests aren't really automated tests, because you have to manually check the outputs to see if failures are genuine. It's a reminder to do manual checking but it's still not an automated process. > The best testing technique in the world can't save us from developer error. Sure, but using a testing technique that increases developer error is unwise, and snapshot testing has done that every time I've seen it used, so I don't use it anymore.
      - yawaramin 2y ago
        > they tend to fail when something is changed. Then fix the test so that it fails only when something breaks? Do people not fix flaky, overly broad, or incorrect unit tests? How is a snapshot test any different?
        DecoySalamander 2y ago
        A fix here would be to drop snapshot testing altogether, since being flaky and overly broad is a natural result of dumb diffing of your app's output.

recursivedoubts 2y ago

htmx moves the data -> html transformation to the server side and thus should be more testable

eddd-ddde 2y ago

Not really unstable since you generate it and there's no browser modifying it. However you'd still lack client functionality testing.

seanwilson 2y ago

> Having to verify HTML as an output (in comparison to e.g. JSON) is brittle since it will often change just for presentation reasons. For HTML tests, if you target elements by their ARIA role, semantic tag, or by matching against the text/label/title the user would see, it should be robust to a lot of presentation changes (and does some accessibility checks too). It's much more robust than e.g. `body > div > div .card > h2` which are sure to break in tests and slow you down when you make changes later. See Playwright locators for example: https://playwright.dev/docs/locators https://playwright.dev/docs/locators Not sure if this is what you meant, but you can't rely on only the JSON because you can't assume it's been properly transformed into the expected HTML.

yawaramin 2y ago

It's standard practice in the frontend world https://jestjs.io/docs/snapshot-testing https://jestjs.io/docs/snapshot-testing

sensanaty 2y ago
In my experience snapshots have largely fallen out of vogue, at least as far as them blocking deploys goes. They're usually flaky, change often, are slow to test and it's way too easy to have false positives which lulls people into complacency and just regenerating the snapshots as soon as they reach a failure. I'm guilty of that myself, unless I can spot the breakage immediately I pretty much just regen the snapshot by default subconsciously because of how often I've had to do that for false positives
- yawaramin 2y ago
  Then what's to stop you from making any unit test pass by just changing the expectations? The best testing technique in the world can't save us from developer error.
  - Hasu 2y ago
    The problem with snapshot tests is that they tend to fail when something is changed. One property of good tests is that they only fail when something is broken. Snapshot tests aren't really automated tests, because you have to manually check the outputs to see if failures are genuine. It's a reminder to do manual checking but it's still not an automated process. > The best testing technique in the world can't save us from developer error. Sure, but using a testing technique that increases developer error is unwise, and snapshot testing has done that every time I've seen it used, so I don't use it anymore.
    - yawaramin 2y ago
      > they tend to fail when something is changed. Then fix the test so that it fails only when something breaks? Do people not fix flaky, overly broad, or incorrect unit tests? How is a snapshot test any different?
      - DecoySalamander 2y ago
        A fix here would be to drop snapshot testing altogether, since being flaky and overly broad is a natural result of dumb diffing of your app's output.