If I understand correctly, you want to visit a site you control that uses captcha, get the capture image, then send it to a 3rd party API to resolve the captcha, then continue to login to the site.

You can use cy.request to call a 3rd party API:

cy.request('POST', 'http://somesite', body).then((response) => {
    // do something with response.body
})

To get the captcha image from your login screen you could use something like:

describe('my website', () => {
    it('should accept typing after login', () => {
        cy.visit('testURL')
        cy.get('a selector to target your #captcha img').then((captchaImg) => {
            // Now you will have the captcha image itself
            const body = { captchaImg } // prepare the body to send to the 3rd party API
            cy.request('POST', 'http://somesite', body).then((response) => {
                // Process the response to extract the field that you are interested in
                // For instance, you could pull out the string '55+20='
                let captchaText = getCaptchaText(response.body)
                let captchaAnswer = getCaptchaAnswer(captchaText)
                cy.get('captcha text input field').type(captchaAnswer)
                // You will probably need to click a submit button

                // Test the site here, now that you have logged in
                cy.get('input[name="textinput1"]').type('Mazda')
                // assert something
                cy.get('input[name="textinput2"]').clear().type('Axela')
                // assert something else     
            })
        })
    })
})

Doing this extra request each test will slow down your tests considerably. So it is better to test the login flow once, and then try some alternative methods to bypass the login flow of your site for the rest of the tests. At the least, you could try putting the captcha related test logic into a before hook and then run a suite of tests.

Cypress recommend against visiting 3rd party sites in your tests for several reasons, documented in this answer. And they also recommend against testing sites which you don't control. But accessing a 3rd party API can be done with cy.request.

Worked it out:

cy.get('#mydatefield').type('2010-01-55')
    .should(($mydatefield) => {
        expect($mydatefield.get(0).checkValidity()).to.equal(false);
        expect($mydatefield.get(0).validationMessage).to.equal('Invalid date');
     });

Accessing new windows via Cypress is intentionally not supported.

However, there are many ways this functionality can be tested in Cypress now. You can split up your tests into separate pieces and still have confidence that your application is covered.

1. Write a test to check that when performing the action in your app, the window.open event is called by using cy.spy() to listen for a window.open event.

cy.visit('http://localhost:3000', {
  onBeforeLoad(win) {
    cy.stub(win, 'open')
  }
})

// Do the action in your app like cy.get('.open-window-btn').click()

cy.window().its('open').should('be.called')

2. In a new test, use cy.visit() to go to the url that would have opened in the new window, fill in the fields and click the buttons like you would in a Cypress test.

cy.visit('http://localhost:3000/new-window')

// Do the actions you want to test in the new window

Fully working test example can be found here.

I made a thing that works :)

envTypeWriter.mjs

import dotenv from 'dotenv'
import fs from 'fs'

const env = dotenv.config({ path: '.env.local' }).parsed
const typeText = `type TEnvKey =\n  | "${Object.keys(env).join('"\n  | "')}"`

fs.writeFileSync('env.d.ts', typeText)

package.json

"scripts": {
    ...
    "types": "node envTypeWriter.mjs"
  },

Then I just do yarn types (and >Reload Window) in vscode).

Don't change my variables that often so this is fine.

Updated version

template:

utils/env.ts

export default function env(key: TEnvKey): string {
  try {
    // have to try catch because of Cypress reference error
    return Cypress.env(key);
  } catch {
    switch (key) {
      // START OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT

// this part will be replaced

      // END OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT
      default:
        return undefined;
    }
  }
}

// START OF AUTO GENERATED TYPES -- DO NOT REMOVE OR EDIT THIS COMMENT
// this will be replaced

envTypesWriter.ts

import { config } from 'dotenv'
import { writeFileSync, readFileSync } from 'fs'

const envLocal = config({ path: '.env.local' }).parsed // NOTE: Script has to be executed from the project root
const typeText = `type TEnvKey =\n  | "${Object.keys(envLocal).join('"\n  | "')}"`

const casesText = Object.keys(envLocal).reduce((acc, key) => {
  acc += `      case '${key}':\n`
  acc += `        return process.env.${key}\n`
  return acc
}, '')

const filePath = 'utils/env.ts'
let text = readFileSync(filePath, { encoding: 'utf8' })
console.log(`reading ${filePath}`)

if (!text) throw 'nothing read'


const casesStartLineMarker =
  '// START OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT\n'
const casesEndLineMarker =
  '      // END OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT\n'

text = `${
  text.split(casesStartLineMarker)[0]
}${casesStartLineMarker}${casesText}${casesEndLineMarker}${
  text.split(casesStartLineMarker)[1].split(casesEndLineMarker)[1]
}`

const typesLineMarker = '// START OF AUTO GENERATED TYPES -- DO NOT REMOVE OR EDIT THIS COMMENT\n'
const [untouchedCode, _types] = text.split(typesLineMarker)
const updatedText = `${untouchedCode}${typesLineMarker}${typeText}`

writeFileSync(filePath, updatedText, 'utf8')

Even though what you have written will work, I personally do not like this approach. For me as a general rule of thumb is that if you are going to add conditional blocks in your test cases, it is worth splitting the test into smaller test cases. Here is how I would have done this:

const credentials = {
  UserType1: {
    login: 'UserType1Login',
    password: 'UserType1Password',
  },
  UserType2: {
    login: 'UserType2Login',
    password: 'UserType2Password'
  }
};

const logInTheUser = (credential) => {
  cy.get('[data-cy=login]').type(credential.login);
  cy.get('[data-cy=password]').type(credential.password);
  cy.get('[data-cy=loginSubmit]').click();
}

describe('Checks login', () => {

  beforeEach('Log in the user', () => {
    cy.visit('/');
    cy.get('[data-cy=loginModalOpen]').click();
  });

  it('prints error and does not redirect if user is blocked', () => {
    logInUser(credentials.blocked);
    cy.get('[data-cy=passwordError]').should('contain', 'User blocked');
    cy.url().should('not.include', '/orders/published');
  });

  it('redirects user of type 2 to stores page', () => {
    logInUser(credentials.UserType2);
    cy.url().should('include', '/stores');
  });

  it('prints error and does not redirect if user does not exist', () => {
    loginUser(credentials.nonExisting);
    cy.get('[data-cy=passwordError]').should('contain', 'No user with such login');
    cy.url().should('not.include', '/orders/published');
  });

  it('redirects user of type 1 to published orders page', () => {
    loginUser(credentials.UserType1);
    cy.url().should('include', 'orders_all/published');
  });

  // ...other tests
});

As you can see, the test descriptions are also more descriptive and helps the reader to understand at first glance which test failed.

You you can also do the same by storing all the assertion information in (e.g url, passwordError etc) in the objects that you were iterating over but at that point, you might as well just create separate test cases, which is easier to read and understand what's going on.

This could be bad advice, but can you try the following?

cy.findAllByRole('rowheader').eq(2).click({force: true})

The beforeEach() allows skipping.

Try this

  context("Conditional run", () => {
    let skip = false;
    before(() => {
        cy.get("div").then(($div) => {
            if (!Cypress.$("div[title='OK']", $comp).length) {
                skip = false
            } else {
                skip = true
            }
        });
    });

    beforeEach(function() {    // use regular function here
      if (skip) this.skip();
    })
  });

It might also work just putting the skip call in the before, since you want to skip all tests.

  context("Conditional run", () => {

    before(function() {    // use regular function here

        cy.get("div").then(function($div) {    // not sure if function is needed here
            if (Cypress.$("div[title='OK']", $comp).length) {
                this.skip();
            }
        });
    });
  });

Since it works when the intercept is moved up in the command order, it seems that cy.waitLoading() triggers the POST and not cy.get('[data-cy=alreadysent-button]').

The intercept must always be set up before the trigger (page visit or button click).

But the intercept varies between tests, so instead of before() I would try setting up a helper function that is called at the top of each test.

const loadAndIntercept = (apiResult) => {     
  const apiFixture = apiResult ? 'test/alreadySent-true.json' : 'test/alreadySent-false.json';
  cy.intercept('POST', '**/test/alreadySent', { fixture: apiFixture }).as('alreadySent');
  cy.waitLoading();
})

it('false test', function() {
  loadAndIntercept(false);
  cy.wait('@alreadySent');
  cy.get('[data-cy=alreadysent-button]');
});

it('true test', function() {
  loadAndIntercept(true);
  cy.wait('@alreadySent');
  cy.get('[data-cy=alreadysent-button]');
});

This should work since intercepts are cleared between tests. Ref docs - intercept

Note: all intercepts are automatically cleared before every test.

As mentioned by @richard-matsen, you should check that your loader exists before waiting for it to disapear. That may be why you get the detached from DOM error with your switch-to-staff element.

Something like this might work for you:

Cypress.Commands.overwrite('visit', (originalFn, url, options) => {
  originalFn(url, options);
  cy.get('[data-cy="loader"]').should('be.visible');
  cy.get('[data-cy="loader"]').should('not.be.visible');
});