How to use showSaveDialog method in Cypress

You can use cy.visit with the href attribute, then write an assertion and go back easily xD

cy.get('li').each((item) => {
  const title = item.find('h1').first().text();
  const link = item.find('a').first();

  cy.visit(link.attr('href'));

  cy.get('h1').should('have.text', title);
  cy.go('back');
});

As Fody mentioned, there are node.js functions present inside simple-ssh so a task is needed.

This is the basic configuration.

It's a direct translation of what you have, but you would want to return something from the task. As it is, the console.log() goes to the terminal console not the browser console.

cypress.config.js

const { defineConfig } = require('cypress')
const fs = require('fs')
const SSH = require('simple-ssh');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('task', {
        ssh() {
          const sshConfig = config.ssh
          sshConfig.key = fs.readFileSync('path/to/key/file')
 
          const ssh = new SSH(sshConfig)      
          ssh.exec('echo', {
            args: ['$PATH'],
            out: function(stdout) {
              console.log(stdout);
            }
          }).start();

          return null
        },
      })
    }
  }
})

test

Cypress.Commands.add('ssh', () => {
  cy.task('ssh')
})

cy.ssh()

You can expose db on the window

// useSomething.js

import { useState } from 'react'
import * as db from './db'

const { getData } = db;

if (window.Cypress) {     // only when testing
  window.db = db;
}

and in the test

cy.window().then(win => {
  cy.stub(win.db, 'getData').resolves(something);
})

Or use intercept to stub the API call.

If I add cy.wait(800) ... it works fine.

This is because you are not using Cypress commands with auto-retry inside getInDocument().

Cypress.$(selector) is jQuery, it just attempts to grab the element, not retry for async loading, and no test failure when not found.

Should use a proper command with retry, like

Cypress.Commands.add('getInDocument', { prevSubject: 'document' }, (document, selector) =>
  cy.wrap(document).find(selector)
)

or you might need to work from body

Cypress.Commands.add('getInDocument', { prevSubject: 'document' }, (document, selector) =>
  cy.wrap(document).its('body')
    .find(selector)
    .should('be.visible')
)

Without a test system I'm not sure exactly which one is correct syntax, but you get the idea.

Also, too many custom commands. You always follow .iframeLoaded() with .its('document'), so just wrap it all up in iframeLoaded custom command.

In fact, resolve(contentWindow.document.body) because it's a better point to chain .find(selector).

This is my test against the Stripe demo page,

Cypress.Commands.add('iframeLoaded', { prevSubject: 'element' }, $iframe => {
  const contentWindow = $iframe.prop('contentWindow')
  return new Promise(resolve => {
    if (contentWindow && contentWindow.document.readyState === 'complete') {
      resolve(contentWindow.document.body)
    } else {
      $iframe.on('load', () => {
        resolve(contentWindow.document.body)
      })
    }
  })
})

it('finds card number', () => {

  cy.viewport(1000, 1000)
  cy.visit('https://stripe-payments-demo.appspot.com/')
  cy.get('iframe')
    .should('have.length.gt', 1)  // sometimes 2nd iframe is slow to load
    .eq(1)
    .iframeLoaded()
    .find('input[name="cardnumber"]')
    .should('be.visible')
})

The cleanest way is using cy.each()

const order = ['130', '100' , '1']

cy.get('[data-object-type="playlists"]').each(($el, index) => {
  expect($el.attr('data-object-id')).to.eq(order[index])
})

where $el.attr('data-object-id') uses jQuery to extract the id attribute.

An equivalent using .invoke() would be

const order = ['130', '100' , '1']

cy.get('[data-object-type="playlists"]').each(($el, index) => {
  cy.wrap($el)
    .invoke('attr', 'data-object-id')
    .should('eq', order[index])
})

This has the advantage that .should() uses retry if the table is loaded asynchronously.

For me mouseover works. It's a known Cypress bug pending to be solved. However, try these:

cy.get('#gh-Alerts-i').trigger('onmouseover')
cy.get('#gh-Alerts-i').trigger('mouseenter')
cy.get('#gh-Alerts-i').invoke('trigger', 'contextmenu')
cy.get('#gh-Alerts-i').rightclick();

I implemented testing for a multi-lingual site that supported 40 language locales by using this trick:

1. Define one dictionary (JSON file) for each locale. In the locale file, define the mapping between element ID and text.

2. Write the test suite to take 'locale' as the parameter / environment variable. Test cases will refer to the appropriate dictionary file, based on the locale parameter. Test case will do the assertions based on the mappings defined in locale dictionary.

3. Run test suite with locale as the parameter. This had helped me avoid lot of if-else conditions and switch blocks!

It also helped run tests for only specific languages for a release. (Scenario where not all language sites were updated for every release)

You can simply use should to assert it doesn't exist, and Cypress will wait for the element until it's removed from DOM. If you need to override the default 4s timeout, you can pass it to the previous command:

cy.get( selector, { timeout: 10000 }).should("not.exist");

Shallow rendering (which you are using for your current tests) only renders one level deep. This means that you won't be able to simulate the render() method or the behaviour of child components using the shallow renderer. See the documentation here for more info.

If you want to effectively unit test this code example, you shouldn't try and simulate its child behaviour. Instead, you should test the <Parent /> and <Child /> separately. This prevents changes in your Child component affecting the test results in your Parent component, or vice versa. This is pretty much the whole reason the shallow renderer exists! From the documentation:

Shallow rendering is useful to constrain yourself to testing a component as a unit, and to ensure that your tests aren't indirectly asserting on behaviour of child components.

I would write this test for the child component, using a mock function for its onChildClick prop:

test('triggers its onChildClick prop when clicked', () => {
    const mock = jest.fn()
    const wrapper = shallow(<Child onChildClick={mock} />)
    wrapper.find('.toggle').simulate('click')
    expect(mock).toHaveBeenCalledTimes(1)
})

And I would write this test for the parent, passing in the data to ensure the child is rendered:

test('sets its state when its child is clicked', (done) => {
    const wrapper = shallow(<App data={{ test: 'test' }}/>)
    expect(wrapper.state('enable')).toBe(false)

    wrapper.find('Child').props().onChildClick()
    expect(wrapper.state('enable')).toBe(true)
})

Just tried both of these tests and they work fine. I'm testing the full functionality of the components here, except the process is separated into units. The child triggers its onChildClick prop when the button is clicked, and triggering that prop inside the parent sets the state of enable to true.

Full-DOM rendering (with mount(<Parent />))is a lot more messy, and I only really find it useful for testing components that use DOM apis (which shouldn't happen much in React anyway). Have a look at the documentation again for a fuller explanation!

If you want to test larger-scale features of your app (which it looks like you do), I'd suggest using an end-to-end testing framework like Cypress.

Also, one last thing... you're using wrapper.find('toggle'), but if you want to find a node by its className, then you need to do wrapper.find('.toggle') instead.

Hope this helps!