do you have a simple reproducible repo?

Hi team

I got the issue related to shadow dom, I'm unable to get the value of shadow dom

If you had worked on this, could you please help me this one

I tried with cy.get('.shadow-host').shadow().find('.my-button') but it didn't work

Does anyone know why this test passes locally (visually and in terminal) but fails on Gitlab CI?

it.only('toggles bold with no selection via keyboard shortcuts', () => {
        function Test() {
            const [value, setValue] = useState(emptyRichTextValue);
            const handleChange = newValue => setValue(newValue);
            return (
                <RichText value={value} onChange={handleChange} />
            );
        }
        mount(<Test />);

        cy.get('[data-test-key*="rich-text"] [contenteditable]').first().click();
        cy.get('body').type('{meta+b}Hello');
        
        cy.get('[data-test-key*="rich-text"] [contenteditable]').should('have.text', 'Hello');
        cy.get('[data-test-key*="rich-text"] [contenteditable] strong').should('exist');
    });

Errror is

AssertionError: Timed out retrying after 4000ms: Expected to find element: `[data-test-key*="rich-text"] [contenteditable] strong`, but never found it.

Guys, I have this problem with element visibility and it's quite mind-boggling to me. There is a questionnaire in the app. The test flow is: 1. Start some proccess in app => questionnaire appears and it's reflected in DOM ✅ 2. User doesn't fill questionnaire and proccess finishes => questionnaire disappears from page and gets

visibility = hidden

in DOM. So far so good ✅ 3. There is an option to complete questionnaire after proccess had finished. User clicks button to display this questionnaire => it appears, BUT there is new identicall instance of this questionnaire in DOM and according to CSS classess it's visible. ✅ So right now in DOM we have 2 questionnaires - one hidden which is of no interest to me and second one which is visible (acc. to CSS at least). 4. Cypress tries to grab some field from second questionaire but it fails. I'm getting error from screenshot. 📛 I did some debugging and found out that Cypress doesn't see second questionnaire at all. It keeps founding only hidden questionnaire. Explicit wait doesn't even work, which leads me to conclusion that I'm missing something about

cy.get

. Yet I didn't find anuything helpful online :< Maybe you could help out? 🙂

I think this will be one of those problems that need a special clever CSS selector. If you try and get that element, does it return multiple elements or just the one?

Have you recorded a video of the test and stored it in the build artefacts?

Sorry took so long to get back to you. I had cypress in lower case in the file and it was breaking it

really needs a reproducible repo so that someone could help what is under the div?

can you copy the full code or show a repro? It's hard to tell without dashboard or video artifact what is or not happening. What happens with a hard wait after the mount? Is the same browser being used? Headed vs headless? What are local cy run results like vs cy open?

it's possible that on step 4 the test runs faster than the DOM changes, so you have to make step by step assertions to ensure the DOM state you want, vs letting the test run too fast and the test thinks nothing exists

look at you with your "make step by step assertions" reasonable advice

it's so hard without reproducible code, you can at best guess the problem wish there was something to play with so we can show the solution

How to get list of tags with cypress-cucumber-preprocessor?

.length

keeps returning 1 element only (hidden one).

Sure, it's reasonable advice 😉 But I fail to understand how it might be helpful when 5s explicit wait is not helping 🤔

Then I'm going to make an assumption that the selector isn't correct.

I don't think so. It's just id-selector

cy.get('#questionnaire')

. Take a look. In the screenshots you can see that despite waiting 5s Cypress keeps finding only one instance of this id. I also provided ss from devtools showing that there are in fact 2 questionnaires and only one has class

hidden

.

Ahhh I see, then that is funky.

Just want to rule it out: your second

#questionnaire

(the one you're interested in), is it housed within an

iframe

?

No iframes throughout all app code

I'm running into some trouble trying to fixture/intercept requests for binary audio data (wav files). I've created a repro here: https://github.com/manodrum/cypress-audio. If you comment out the intercept (https://github.com/manodrum/cypress-audio/blob/master/cypress/integration/1-getting-started/audio.spec.js#L30-L36) then the audio plays fine if you serve the audio file locally. But when using the fixture with binary data, something gets modified to where the audio data is no longer valid. It seems like there were issues with this back in version 6, but we are on version 9. I even added

istextorbinary

to test the payload from the fixture, and it is detected as binary.

I'm adding crypress to my project for integration tests. I'm surprised this assertion failed:

ts
expect(response.body).to.be.instanceOf(Array)

sh
AssertionError: expected [ Array(1216) ] to be an instance of Array

I wasn't worried about the length. How should I be doing this test?

nvm. I figued it out:

expect(response.body).to.be.an("array")

Hi. Does anyone know why Cypress is loading the page in the

beforeEach()

hook? I see the new url event, but I still don't understand why does it happening, since in the beforeEach() hook I only preserve cookies and do some API calls, so I don't want/need to have my baseUrl page loaded...

My hunch is that the application (not Cypress) is still performing steps caused by the first scenario You can verify this by using

it.only()

in that second scenario

Looks like you are right. But is this a valid behavior? Shouldn't everything from the previous test be stopped/ignored when beforeEach for the next test starts?

Yeah, it’s something I’ve observed in Cypress myself on occasion. Hasn’t caused me issues other than adding noise, though. We probably need one of the devs to weigh in on what is expected behaviour