do you want to test that side-effects happen? or to avoid them, so that things are more cleanly testable?

test them

sadly, no one pays me for code that is pure 🙂

what do you use for frontend? with re-frame you should have effect segregation for free

the state is handled by react hooks locally in react components so it's not easy to test state transitions. There are specific situations that I want to avoid, so I was thinking I could run the app with generated data and test that specific situations don't occur. Like there is always a button to click or always a feedback message is shown

the time I started this project re-frame didn't support hooks, which were required by my boss and colleagues

so I use helix

not sure if I'd run Spec's generative testing (specifically, spec.test.alpha/check) with side-effectful functions. IME it's the kind of thing that is painful/slow to implement, and later to debug It might be cleaner to generate data with Spec, and pass said data to a vanilla integration test (whether a purely frontend-bound one, or a full-stack one aided by Webdriver)

For completeness, with re-frame I think it's feasible to craft a useful generative test that asserts that interactions always yield a valid application state e.g. click X + click Y, in any order, generate events a, b, c all of which are valid and form a valid new app state All this side-effect free (thanks to the indirection bought by events)

The first suggestion with the integration test makes sense, it's what direction I was going, but I wasn't sure if there is no other way.

The second part with re-frame I don't understand, or maybe I understand just don't see how it is relevant?

I do stateful generative testing but not on the frontend, so I can't help with specifics there. But I can confirm what @U45T93RA6 says - it is a bit painful and slow to implement. I've gone through a few iterations and am finally at a spot where I think we are taming the beast, but it's taken some work getting there and we have some work to go to get it running in a more reasonable amount of time.

> The second part with re-frame I don't understand, or maybe I understand just don't see how it is relevant? it's relevant because it attempts to show how one could write a generative, integration-ish side-effect-free test using a specific framework. Don't know helix myself so yeah it may have limited utility :)

I still don't understand, are you saying I should use a different library? Or framework, although I do not use frameworks so I hesitate to use the word framework.

no, I'm stating a technique that may be translated to other (but not all) libraries/frameworks

Wouldn't that mean that I would have to start over and write the whole thing in a different style?

so are you saying this for consideration for future projects?

IDK, I don't know helix so I don't know how practical the described techique could be for you. In the end it's just food for thought :)