How to use loadBinaryFromFile method in Cypress

You can also use .hasClass('disabled') as there is a class disabled added. Also since there would multiple arrow buttons use an each instead of a then.

it('Validate the button is clickable', () => {
  cy.get('.arrow')
    .should('be.visible')
    .each(($btn) => {
      if ($btn.hasClass('disabled')) {
        cy.wrap($btn)
          .should('have.class', 'disabled')
          .and('have.css', 'background-color', 'rgb(62, 64, 69)')
        cy.log('Arrow is disabled and not clickable')
      } else {
        expect($btn).to.have.css('background-color', 'rgb(172, 42, 0)')
        cy.wrap($btn).click()
      }
    })
})

Cypress modifies chai.expect but does not seem to add a way to turn off logging.

If you import from node_modules you can run the original and avoid the log.

const chai = require('chai');

it('expects witout log', () => {
  chai.expect(USER).to.be.a('string').and.to.not.be.empty;  // no logging happening
})

Try it with a regex to parse the ref.

Using /\(REF([0-9]+)\)/ you get two matches,

• matches[0] is the whole "(REF123456789)""
• matches[1] is the inner group "123456789"

cy.get('div.notification-content')
  .then($el => $el.text().match(/\(REF([0-9]+)\)/)[1])  // parsing step
  .then(ref => {
    webpage.RefNo().type(ref)
  })

In your function,

export function addRefToRef() {    
  cy.get('[class="ref-success"]').find(':selected').contains('REF')
    .then(($clipboard) => {
      const copiedRef = $clipboard[0]._vClipboard.clipboardAction.text;
      const innerRef = copiedRef.match(/\(REF([0-9]+)\)/)[1];

      // <<filler steps, moving around pages>> //

      webpage.RefNo().type(innerRef)
    })
}

@jmargolisvt is correct, if you change the .click() operation to a Cypress command, you should get the correct sequence of actions.

Command execution sequence and test loops

Think of it like this - the test code above runs as normal javascript, and each cy.X() command puts a command into the queue. Commands are guaranteed to run sequentially in the queue order, but not synchronously with the test code.

So, the the cy.wait(2000) is not slowing down the for-loop, it's pausing the queue execution.

Waiting for assertions

Note also that commands have built-in waits for their assertions, so you probably don't need either the cy.wait() or the cy.waitUntil() in this scenario. You can control the maximum time for waiting with a timeout option.

Looping

The for loop will work ok if you convert the inner parts to commands, but you can also convert the loop itself to a cy.get().each() command which IMO is much neater.

Testing async content

Lastly, prefer cy.contains('mySelector', 'myContent') command to cy.get('mySelector').contains('myContent') command when waiting for async content.

The reason is cy.get('mySelector').contains('myContent') only waits on the element mySelector, but it's already in the DOM. If the content is asynchronously changing, this command will test the old content (presume empty) immediately and fail the test.

const tbodySelector = '#root > section > section > main > div > div > section.instances > div > div > div > div > div > div > table > tbody';
const buttonSelector = 'td:nth-child(7) > div > button.ant-btn.ant-btn-primary.ant-btn-sm';
const spanSelector = 'td:nth-child(3) > span'

cy.get('.instances__action').each(($el, i) => {

    cy.get(`${tbodySelector} > tr:nth-child(${i+1}) > ${buttonSelector}`)
      .click();

    cy.contains(
      `${tbodySelector} > tr:nth-child(${i+1}) > ${spanSelector}`, 
      'Finished', 
      { timeout: 2000 }  // increase timeout if a longer wait is required
    );  

});

---

NOTE jQuery's :nth-child(index) selector starts at index 1, but .each(($el, i) => has zero-based indexes, so must use i+1 within these selectors.

---

This is the mock DOM I used to test with. In a clean Cypress project, put it in folder <project root>/app.

<table>
  <tbody>
    <tr class="instances__action">
      <td>
        <button id="myBtn1"></button>
      </td>
      <td>
        <span id="mySpan1"></span>
      </td>
    </tr>

    <tr class="instances__action">
      <td>
        <button id="myBtn2"></button>
      </td>
      <td>
        <span id="mySpan2"></span>
      </td>
    </tr>
  </tbody>
</table>
<script>
  document.getElementById("myBtn1").addEventListener("click", function() {
    setTimeout(() => {
      document.getElementById("mySpan1").innerHTML = "Finished";
    }, 1000)
  });
  document.getElementById("myBtn2").addEventListener("click", function() {
    setTimeout(() => {
      document.getElementById("mySpan2").innerHTML = "Finished";
    }, 500)
  });
</script>

Note the nesting above is simplified, so I changed the selector contants appropriately.

Testing the above HTML fragment

it('clicks buttons and waits for finished flag', () => {

  cy.visit('app/iterate-table-buttons.html')

  const tbodySelector = 'tbody';
  const buttonSelector = 'td:nth-child(1) > button';
  const spanSelector = 'td:nth-child(2) > span'

  cy.get('.instances__action').each(($el, i) => {

      console.log(`starting #${i}`)

      cy.get(`${tbodySelector} > tr:nth-child(${i+1}) > ${buttonSelector}`)
        .then(() => console.log(`clicking #${i}`))
        .click();

      cy.contains(
        `${tbodySelector} > tr:nth-child(${i+1}) > ${spanSelector}`, 
        'Finished',
        { timeout: 2000 }  // increase timeout if a longer wait is required
      )
      .then(() => console.log(`asserting #${i}`))

  });
})

Cypress log

This is what the Cypress log looks like.
All green, and can see the clicks only happen after the Finished text appears.

1. VISIT app/iterate-table-buttons.html
2. GET .instances__action
3. GET tbody > tr:nth-child(1) > td:nth-child(1) > button
4. CLICK
5. CONTAINS tbody > tr:nth-child(1) > td:nth-child(2) > span, Finished
6. GET tbody > tr:nth-child(2) > td:nth-child(1) > button
7. CLICK
8. CONTAINS tbody > tr:nth-child(2) > td:nth-child(2) > span, Finished

Console log

This is what the console logs look like.

The loop executes to completion before the command queue even begins, but that's ok because the commands are still executing in correct order.

starting #0
starting #1
clicking #0
asserting #0
clicking #1
asserting #1

This is not yet implemented, see this open issue: issue link. There are however some hacky ways around that, and some third party packages that might help: cypress upload

From the order of events you've given

1. short URL returned
2. added to localStorage
3. added to list

just change the order of feature testing

1. test list - it is last event, but has retriable commands (you can increase the timeout)
2. now test localStorage, if UI has the short URL so will localStorage

cy.contains('.shortener-component__list-item', 'https://facebook.com', { timeout: 40000 })
  .then(() => {

    // nested inside .then() so that the above passes first

    const localStorageData = localStorage.getItem("linksData");
    const linksData = JSON.parse(localStorageData);
    expect(linksData).not.to.eq(undefined);
    expect(linksData[0].inputValue).to.eq("https://facebook.com");
  })

---

Alternatively, to make use of retry and timeout on the localStorage check,

cy.wrap(localStorage.getItem("linksData"))
  .should('not.eq', undefined, { timeout: 40000 }) // will retry the above until true
  .then(data => JSON.parse(data))
  .should(parsedData => {              
    expect(parsedData.inputValue).to.eq("https://facebook.com");
  });

I guess you should also start the test with

cy.clearLocalStorage("linksData")

You say "The problem is, when I return the value, the variable is undefined".

That's because the return myNumber line runs before the cy.get(this.labelWithText).then(($element) => { completes, because the command is running asynchronously.

You need to return the command itself, and also the derived myNumber is returned from inside the .then().

public getValueFromElement(): Chainable<string> {  // cannot return the raw string 
  cy.log("Obtaining the Value");
        
  return cy.get(this.labelWithText).then(($element) => {
    ...
    const myNumber = splittedText[1]; 
    cy.log("Inside the THEN " + myNumber)
    
    return myNumber
  })
}

Use it like this

getValueFromElement().then(myNumber => {
  cy.log("Outside the function " + myNumber)
})

I've got Cypress tests running for several environments, one of those has issues with the login state. Deleting cookies helps sometimes, but not always. So to keep the tests stable I decided to create an if statement (what in itself isn't a best practice) to go to the known application state as fast as possible.

What I do is using the custom command below in every beforeEach() that could use a login:

Cypress.Commands.add('login', function () {
    cy.get('body').then($body => {
        if ($body.find('.user-profile-name').length === 1) {
            cy.log('Already logged in')
        } else {
            cy.get('.login-button').click()
        }
    })
})

What is does is checking if the browser is already logged in, since .user-profile-name should exist. If it does not exist the browser isn't logged in, so Cypress needs to click the .login-button button.

You can have Cypress retry the expectation by changing .then() to .should().

I would also change the order you obtain the elements, since .should() retries the preceding command only.

it('should center the spider by left border', () => {
  cy.get('.wall').then(($wall) => {
    cy.get('.spider')
      .should(($spider) => { // repeat .get(spider) until except succeeds, or times out
        ...
        expect(spiderLeft).to.equal(spiderLeftAbs);
      });
  });
});

Also works with triggerable transitions, I tested with a hover transition (using cypress-real-events).

<style type="text/css">
  .target {
    font-size: 14px;
    transition: font-size 1s 1s;
  }
  .target:hover {
    font-size: 36px;
  }
</style>

BTW you may need to use some +/- on the pixels.