Figured out the answer using cy.stub() method as advised by Richard Matsen:

describe('Test an alert and the text displaying', function() {
it('Verify alert and its text content', function(){
    cy.visit('http://www.seleniumeasy.com/test/javascript-alert-box-demo.html')    

    const stub = cy.stub()  
    cy.on ('window:alert', stub)
    cy
    .get('button').contains('Click me!').click()
    .then(() => {
      expect(stub.getCall(0)).to.be.calledWith('I am an alert box!')      
    })  

    })

})

Make sure that you return that promise inside Cypress.Commands.add callback. It's a bit confusing to deal with promises in Cypress context, since a lot of async behavior is magically handled within cy. commands.

Cypress.Commands.add("login", () => {
  return AuthLib.signIn(username, password).then((data) => {
    cy.setLocalStorage("accessToken", data.accessToken);
  });
});

Other solution:

Cypress.Commands.add("login", () => {
  return AuthLib.signIn(username, password);
});

before(() => {
  cy.login();
  cy.setLocalStorage("accessToken", data.accessToken);
});

Apply a .filter() with a jQuery expression:

cy.get('li[data-testid="wrapper"]')
  .filter((i,li) => Cypress.$(li).find('p').length === 3 )
  .first()
  .click()

These alternatives also work:

.filter((i,li) => Cypress.$(li).find('.selections').children().length === 3 )
.filter((i,li) => Cypress.$(li).find('[data-testid^="selection"]').length === 3 )

Problem

I understand the intention of the Gatsby documentation avoid executing useStaticQuery, but the approach implicitly recommends leaving code uncovered.

Recommendation

To achieve code coverage, the most logical thing to do would be to either mock useStaticQuery or better yet use MockProvider.

GraphQL Testing: MockProvider - https://www.apollographql.com/docs/react/development-testing/testing/#mockedprovider

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)
            })
    })
})

Add users to the fixture keyed by an id

authsettings.json

{
  "user1": {
    "username": "xxUsername",
    "password": "xxPassword"
    ...
  },
  "user2": {
    "username": "xxUsername",
    "password": "xxPassword"
    ...
  },
  ...
}

In auth.js is gets a bit tricky since you have some closures on the initial import, for example

const buildIdTokenEntity = (homeAccountId, idToken, realm) => {
    return {
        credentialType: "IdToken",
        homeAccountId,
        environment,
        clientId,                    // closure from above (not a parameter)
        secret: idToken,
        realm,
    };
};

You could set the desired userid in an environment variable, so the top of auth.js becomes

import authSettings from "./authsettings.json";

const userId = Cypress.env('userId');
const {
    authority,
    clientId,
    clientSecret,
    apiScopes,
    username,
    password,
} = authSettings[userId];

In the tests,

it('tests user1', () => {
  Cypress.env('userId', 'user1')
  ...
})

Also use a default in Cypress configuration

// cypress.config.js

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:1234'
  },
  env: {
    userId: 'user3'
  }
})

Timing

The above is your smallest change, but I suspect it won't work since Command.js is imported in cypress/support/e2e.js and executes the auth.js import before the test runs.

If that's the case, you will need to pass userId into the login

test

describe('Login with MSAL as xxUsername', () => {
beforeEach(() => {
    cy.LoginWithMsal('user2')
})

Commands.js

Cypress.Commands.add("LoginWithMsal", (userId) => {           // receive here
    if (cachedTokenExpiryTime <= new Date().getTime()) {
        cachedTokenResponse = null;
    }
    return login(cachedTokenResponse, userId)                 // pass here
      .then((tokenResponse) => {
        cachedTokenResponse = tokenResponse;
        cachedTokenExpiryTime = new Date().getTime() + 50 * 60 * 1000;
      });

auth.js

import authSettings from "./authsettings.json";

let                                        // const -> let to allow change
    authority,
    clientId,
    clientSecret,
    apiScopes,
    username,
    password;

...

export const login = (cachedTokenResponse, userId) => {

  authority = authSettings[userId].authority;
  clientId = authSettings[userId].clientId;
  clientSecret = authSettings[userId].clientSecret;
  apiScopes = authSettings[userId].apiScopes;
  username = authSettings[userId].username;
  password = authSettings[userId].password;

  ...

You could reduce that down if some of the credentials are common to all users.

As suggested at https://github.com/vuejs/vue-test-utils-next/issues/194#issuecomment-695333180

Changing the shim to the below fixes the issue.

declare module '*.vue' {
  import { DefineComponent } from 'vue';
  const component: DefineComponent;
  export default component;
}

It is very difficult to test a situation where an action has not occured. With this type of assertion, you can really only say:

"The XHR request was not made within the 400ms that Cypress looked for this XHR request to have been made (or whatever you set your timeout to be)"

This doesn't really confirm that the XHR request was never called.

That being said, Cypress offers a way to retrieve all XHR requests made using the undocumented cy.state('requests'). You could check the length of that, filter them by alias, etc to probably determine what you want.

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.