I don't know what the consensus is, but my conclusions so far about testing UI in general are: • Test the data transformation logic separately. • Testing interactions is of limited use outside of end-to-end testing, simulate the user, not the surrounding code. • It's difficult and time consuming to write automated UI tests that don't break. • You have to actually look at the thing and use it manually regardless of what you automated. Maybe there are smarter people who figured this out and came to more nuanced conclusions though.

+1 on @U01EFUL1A8M’s list. Been doing front-ends for forty years, and do not see how automated testing could ever work. For separate QA teams, a manual script of "things to test" is great. tbh, the quality effort should be invested in a quality UI framework. It does not have to be reactive, but it helps. So Reagent gets a +1, but the reactivity of Reagent is not unified, so maybe +1/2. Second, either use experienced UI devs who know instinctively what to test while they are coding, or provide noobs with a "things to test" list.

In my experience, automated UI testing never works. It requires either the HTML structure staying the same or the visual identity staying the same, which causes so many false positives that you're better off just not doing it.

separate your logic out as much as possible and test that part.

It's interesting that others have come to the same kind of conclusions. I wonder if the mentioned hindrances are inherent to UI testing or if they are inherent in how UI is coded in the first place. Generating the UI is typically the last step of a pipeline that gets increasingly concrete and in many ways also imperative. I saw a recent [talk](https://www.youtube.com/watch?v=Mjn92fODdaA) about #CVB8K7V50 and there might be a hint towards making UI programming easier to reason about and ultimately also easier to test? It's an open question.

Well, we start with an impedance mismatch: we want to run automatically a test requiring user input, checked by what the user would see. Second, we especially need the test to work, not during original development, rather after the UI component has changed, or has been involved in a larger refactoring. So, as usual with regression testing, we will more often have to alter the test than fix the code, which is actually OK. I think #CVB8K7V50 solves the first problem by saying, no, a UI is now just a data transformation. So there is a nice divide-and-conquer win there. Not sure any test survives a change in functionality,

1. You have installed React 18. Currently, by default Reagent supports only 17. There was some work to support 18 but IIRC there are still some hiccups 2. How do you use show? If you log YouTube, does it appear as a component or as an export object?

The export statement says export default YouTube. So maybe try ["react-youtube$default" :as YouTube].

yep that was it 😄 Many thanks @U2FRKM4TW you are lifesaver. Finally youtube embed works

> there are still some hiccups Pun intended? :rolling_on_the_floor_laughing:

Ha! No, not at all. :)