What is a good way to unit test if a component is rendering what I expect it to? Can anyone point me to an example?

@boccato I don’t personally suggest those kinds of tests (more cost than benefit usually), but there are three approaches: 1. Use headless rendering, take image, save image, future tests diff images. 2. Use CLJC for the component, and use SSR to emit DOM strings. Check for content in the strings. 3. Use React tools and approaches, since Fulcro components are React components: https://reactjs.org/docs/testing.html

All suffer from high fragility (lots of false positives), so their utility in regression is limited….browser CSS is just as likely to cause a problem (if not more) than your code output. All sorts of uselessness down this path.

IMO 😜

I understand you. I just want to check more general stuff, like whether the login screen is showing when session/active is false or that a field is only shown in certain circunstances.

It is not to test layout or other "visual" stuff.

I would suggest using something like react-testing-library

You avoid testing implementation, save any test-ids you choose to use

@tony.kay What type of testing do you suggest I do on the front end as an alternative?

you could also try tools that let you record ui actions, make assertions, and play them back. https://get.testim.io/, https://ghostinspector.com/, etc

I generally test logic, not UI. Smoke testing (via full stack UI testing) can be valuable, but I would do it with tools that acutally drive a browser against a well-known testing server.

https://www.cypress.io/ is worth a look.

I find pure front-end testing to be not particularly useful

I find the approach of seing the ui as a function of the app state to help a lot with removing the logic from the ui. That helps a lot with testing and I almost feel like I don´t have to test the UI (I really dislike selenium and its friends as I feel the tests tend to wonder to details and start taking too long to run). There is still a few things on that step from state to ui that I feel are still important. I wonder if I am not passing the opportunity to put a little more logic on the app's state and dumb down the UI even more...

the dumber the UI the better. I still usually want some kind of smoke tests…it’s making them effective (in cost and utility) that is always a challenge

Sure, it is important to have something that tests the whole thing. I find that the more I can do with "unit tests", the less I depend on those "bigger" tests and can keep them minimal.

Thanks both for the tips 🙂

So, I took a look at cypress…it actually seems to work really well. Best thing I’ve seen to date for doing this kind of stuff…only took me 5 mins to get going on my current project. I had to specify a longer typing delay for it to not miss input, but other than that seems pretty nice so far.

I think Cypress is more of a relevant tool now that most browsers are either Webkit or Gecko, save all the IE stragglers

Though I know they were working on cross-browser testing. Not sure where that’s at

well, in my opinion I’m more interested in the full-stack smoke testing aspect of it (detecting regressions or other more serious problems in the software that will affect everyone). It looks like the type function isn’t able to simulate React exactly, so you have to put quite the delay on it with Fulcro (like 100ms per keystroke). I kind of understand why that is, but I’m not sure if it can be helped.

Yeah, it’s definitely set up to act as a real user in a real browser