[bornelsewhere]

An important topic I do not see discussed on HTMX and other such tools is testing.

Frontend frameworks all have a way to unit- and integration-test their components without resorting to Cypress or Playwright. How do you integration-test the effect of your hypermedia enhanced applications without a (headless) browser? Using Chrome for a few end-to-end tests is fine. But it is not a replacement for in process RackTest (to give a Rails specific example).

From a quick glance testing is not addressed in this book either.

[polyrand]

You can write tests just like you would test a JSON API. But instead of testing the JSON structure, you can test the HTML structure. Depending on how deep you want to go, you can parse the HTML response and check for the components, but sometimes just checking for bare strings is enough. For example, taking the FastAPI testing docs[0], instead of:

  assert response.json() == {"detail": "Item already exists"}

You can write:

  assert f"<b>Item already exists</b>" in response.render().decode()

One thing I found using HTMX (or just HTML) is that the apps are less fragile. I know that if I return a chunk of HTML, the browser will render it the same way every time. With a JSON-based SPA, maybe that chunk of JSON ends up triggering multiple side effects, re-renders, etc. which can behave differently depending on the current application state. This all affects the amount of testing that I feel comfortable with.

[0]: https://fastapi.tiangolo.com/tutorial/testing/?h=testing#ext...

[deniz-a]

If I was to test things that were part of UI code, but were still "mechanical" enough to test automatically, I would throw responses into an HTML parser to make sure I'm presenting the right data. (In a way, HTML strings are also a kind of "virtual DOM")! If you need to test interactions though, I don't think a headless browser is avoidable.

[niels_bom]

I would think that because HTMX == less JavaScript that there’s less of a need to test functionality. And the testing that remains will need a browser to be tested. Complex logic will still be written in JavaScript so then one can use regular JS testing tools again.

[bornelsewhere]

We do not test because of a language used but because there are assumptions expressed in code. “Clicking a button validates the email address” is a test you need to have regardless of if it’s implemented as `hx-get` or `onSubmit`. I would argue having good test coverage for the former is more important because the action happens further (another controller+template instead of the same React component).