How to use getLocalFilePath method in Cypress

It is because you are using a shadow DOM

to access use .shadow https://docs.cypress.io/api/commands/shadow

describe("Verify identity data", () => {
  it("Makes an assertion", function () {
    cy.visit("https://whitelabel.sandbox.array.io/signup?platform=v3");
    cy.get("array-account-enroll").shadow().find('input[name="firstName"]');
  });
});

After much nashing-of-teeth, I think I have an answer.

I think the root cause is that mdc-select-item has display:flex, which allows it to exceed the bounds of it's parents (strictly speaking, this feels like the wrong application of display flex, if I remember the tutorial correctly, however...).

Cypress does a lot of parent checking when determining visibilty, see visibility.coffee,

## WARNING:
## developer beware. visibility is a sink hole
## that leads to sheer madness. you should
## avoid this file before its too late.
...
when $parent = parentHasDisplayNone($el.parent())
  parentNode = $elements.stringify($parent, "short")

  "This element '#{node}' is not visible because its parent '#{parentNode}' has CSS property: 'display: none'"
...
when $parent = parentHasNoOffsetWidthOrHeightAndOverflowHidden($el.parent())
  parentNode  = $elements.stringify($parent, "short")
  width       = elOffsetWidth($parent)
  height      = elOffsetHeight($parent)

  "This element '#{node}' is not visible because its parent '#{parentNode}' has CSS property: 'overflow: hidden' and an effective width and height of: '#{width} x #{height}' pixels."

But, when using .should('be.visible'), we are stuck with parent properties failing child visibility check, even though we can actually see the child.
We need an alternate test.

The work-around

Ref jquery.js, this is one definition for visibility of the element itself (ignoring parent properties).

jQuery.expr.pseudos.visible = function( elem ) {
  return !!( elem.offsetWidth || elem.offsetHeight || elem.getClientRects().length );
}

so we might use that as the basis for an alternative.

describe('Testing select options', function() {

  // Change this function if other criteria are required.
  const isVisible = (elem) => !!( 
    elem.offsetWidth || 
    elem.offsetHeight || 
    elem.getClientRects().length 
  )

  it('checks select option is visible', function() {

    const doc = cy.visit('http://localhost:4200')
    cy.get("mdc-select").contains("installation type").click()

    //cy.get('mdc-select-item').contains("ITEM1").should('be.visible') //this will fail
    cy.get('mdc-select-item').contains("ITEM1").then (item1 => {
      expect(isVisible(item1[0])).to.be.true
    });
  });

  it('checks select option is not visible', function() {

    const doc = cy.visit('http://localhost:4200')
    cy.get("mdc-select").contains("installation type").click()

    cy.document().then(function(document) {

      const item1 = document.querySelectorAll('mdc-select-item')[0]
      item1.style.display = 'none'

      cy.get('mdc-select-item').contains("ITEM1").then (item => {
        expect(isVisible(item[0])).to.be.false
      })
    })
  });

  it('checks select option is clickable', function() {

    const doc = cy.visit('http://localhost:4200')
    cy.get("mdc-select").contains("installation type").click()
    
    //cy.get('mdc-select-item').contains("ITEM1").click()    // this will fail
    cy.get('mdc-select-item').contains("ITEM1").then (item1 => {
    
      cy.get('mdc-select-item').contains("ITEM2").then (item2 => {
        expect(isVisible(item2[0])).to.be.true  //visible when list is first dropped
      });
          
      item1.click();
      cy.wait(500)
          
      cy.get('mdc-select-item').contains("ITEM2").then (item2 => {
        expect(isVisible(item2[0])).to.be.false  // not visible after item1 selected
      });
    });
    
  })

Footnote - Use of 'then' (or 'each')

The way you normally use assertion in cypress is via command chains, which basically wraps the elements being tested and handles things like retry and waiting for DOM changes.

However, in this case we have a contradiction between the standard visibility assertion .should('be.visible') and the framework used to build the page, so we use then(fn) (ref) to get access to the unwrapped DOM. We can then apply our own version of the visibility test using stand jasmine expect syntax.

It turns out you can also use a function with .should(fn), this works as well

it('checks select option is visible - 2', function() {
  const doc = cy.visit('http://localhost:4200')
  cy.get("mdc-select").contains("installation type").click()

  cy.get('mdc-select-item').contains("ITEM1").should(item1 => {
    expect(isVisible(item1[0])).to.be.true
  });
});

Using should instead of then makes no difference in the visibility test, but note the should version can retry the function multiple times, so it can't be used with click test (for example).

From the docs,

What’s the difference between .then() and .should()/.and()?

Using .then() simply allows you to use the yielded subject in a callback function and should be used when you need to manipulate some values or do some actions.

When using a callback function with .should() or .and(), on the other hand, there is special logic to rerun the callback function until no assertions throw within it. You should be careful of side affects in a .should() or .and() callback function that you would not want performed multiple times.

You can also solve the problem by extending chai assertions, but the documentation for this isn't extensive, so potentially it's more work.

Friends

Firstly, Thanks for all your time & suggestions.

I have found the work around to trigger the mouseover event and show the bootstrap submenu. without using the { force: true }.

Solution that I implemented. Appreciated if anyone finds different and better solution. Please do share.

Cypress.$($elem[0]).siblings("ul").show();

Using this I have manually makes the ul to show first and then execute the click event of the submenu. For this I have tried

Cypress.$($elem[0]).hover(false, false);
Cypress.$($elem[0]).mouseover();
Cypress.$($elem[0]).trigger("hover");
Cypress.$($elem[0]).trigger("mouseover");

but above commands didn't work. So I move to manually trigger the hide/show event of jquery.

this can be done more easily than that : in your cypress.json add

"env": {
   "YourVarName":"YourVarValue"
}

And in your code you can access to your var with :

const myGolabalVar = Cypress.env("YourVarName")

That's all you need

I don't think aliases are required. Here is my solution that I tested locally. I kept most of the code in Alapan Das' answer so it's easier to compare. To me, it seems more concise and easier to read without aliases.

describe('Store and compare a value', () => {
    it('store and compare', () => {  
        cy.login()
        cy.visit('url2')
        cy.get('.total-count-results').invoke('text')
            .then((previousText) => {
                cy.get('.medium.col100 > .filterwrapper > input').type('Test Dummy',{force: true})
                cy.get('.medium.col100 > .filterwrapper > input').type('{enter}')
                cy.get('.total-count-results').invoke('text').should("eq", previousText)
            })
    })
})

This is a known issue after Chrome 67 enabled by default the site isolation security feature, and it gets reflected in any frameworks that use Chromium releases that include it (e.g. Electron 5+)

http://www.chromium.org/Home/chromium-security/site-isolation

When debugging with --disable-web-security, it may also be necessary to disable Site Isolation (using --disable-features=IsolateOrigins,site-per-process) to access cross-origin frames.

Here are some open issues regarding it

https://github.com/electron/electron/issues/18214
https://github.com/cypress-io/cypress/issues/1951

In Electron 5+, until this is solved you can add this line before app 'ready' event

app.commandLine.appendSwitch('disable-site-isolation-trials');

Cypress have promises (Cypress.Promise), but they are not real promises, more like duck typing. In fact, Cypress isn't 100% compatible with real promises, they might, or might not, work.

Think of Cypress.Promise as a Task or an Action. They are executed sequentially with all other cypress commands.

To get your function into the Cypress pipeline you can use custom commands. The documentation doesn't state it, but you can return a Cypress.Promise from them.

Cypress.Commands.add('resetDb', function () {
  var apiServerUrl = Cypress.config().apiServerUrl;
  return new Cypress.Promise((resolve, reject) => {
    httpRequest('PUT', apiServerUrl + "/api/test/reset/")
      .then(function (data) {
        resolve();
      })
      .catch(function (err) {
        reject(err);
      });
  });
});

That command can then be executed from the test itself, or as in my case from before().

describe('Account', function () {
  before(() => {
    cy.resetDb();
  });

  it('can login', function () {
    // test code
  });

})

You can do something like:

cy.get('table > tbody > tr:nth-child(1) > td:nth-child(1)', {
    timeout: 15000
}).invoke('text').then((text) => {
    expect(text.length).to.be.at.least(5)
})

I have solved this problem. Actually it wasn't even about front, but about my API.

The problem is cypress removes all from localStorage when visits other page, so I had to do some actions to save it in localStorage - login one more time.

So, be careful with this, problem could be in API, not front.