https://cypress.io logo
Join Discord
Powered by
Yep, it is expected to be <sasearchinput> instead ...
# component-testing
s
Yep, it is expected to be instead rendered to . This is because SASearchInput is already tested and CustomComponent cypress test just needs to check if correct props are passed to child component. So the main question is - do you know how to make cypress mount component which child component has object as prop (and displays real component data) So I'd expect it to be rendered to
Copy code
<sasearchinput texts="{\r\ntest1: \"aaa\",\r\ntest2: \"bbb\"\r\n}"></sasearchinput>

instead of

<sasearchinput texts="[objject Object]"></sasearchinput>
I am open to new ideas, like registering sasearchinput in order to render real content of it, but then I think I wouldn't be able to test props, only option would be to check innerTexts etc.
w
If the component is not registered, you'll get a HTML tag with that name, and the idea of "props" doesn't work for a html element - at that point your code is trying to use an object as a HTML attribute, and it's going to get clobbered with 
toString()
. To be more clear what I think is going on: it's not a Cypress issue, it's your JS framework doing its best to convert an attribute value to a string to put it on a HTML element. Without the component registered in the context of mounting the component, the framework doesn't know that this attribute is a prop or that the element name refers to a component, it just thinks you are doing a plain HTML element with a funny name, and putting regular attributes on it.
What framework are we using here? If you do register the child component so it gets mounted, there are ways to inspect its state and see what props it received. Another escape hatch might be to have a data attribute that uses 
JSON.stringify()
to render the props object, so it converts to something you can grab from the DOM. Overall though, I don't generally want to get in the weeds like this with the connections between components in my tests. I think it's more robust to test the props through their impact on the UI - does SASearchInput have the expected appearance & content from a user perspective when used in CustomComponent? I think that's a good way to know if SASearchInput is being used properly without asserting the specific prop names and values. Ideally you could completely refactor the API for SASearchInput and the higher level component tests wouldn't need to be updated at all. If the user-facing functionality in the browser is the same. But if you really want to, you have options.
s
I use vuejs. Thanks Mark, that is exactly what I needed. I'll have to disscuss this with the team, because currently there's hundreds of cypress tests written in a way I described initially, a lot of work it would be to change approach, but i see that's the only not hacky solution
PreviousNext
Powered by