How to use formFullAppPath method in Cypress

After using several test frameworks, I feel the below is better:

For test file names, use as below:

1. /test/*.test.js - preferred, no need to explain.
2. /test/*.spec.js - OK, but new joinees always ask me - why?. A spec here means requirement specification.
3. /test/*.test.txt - preferred, if test cases are in a text file. A set of line(s) is a test case (see below).

For example:

• a.js is the main JavaScript file that should be tested
• /test/a.test.js is the test file that tests above a.js. Note that /test/ is a test folder.

You may find *.test.txt new, so adding more details.

The format of one test case being three lines, can be in the below format in *.test.txt:

• inputParam1 - may be the first parameter of a critical function which needs many tests
• inputParam2 - may be second parameter of a critical function which needs many tests
• expected
• inputParam1
• inputParam2
• expected
• ...

So, every three lines make one test case.

You may add the function name line like below, once in a while, which tests different function:

• -func:someMethod1
• ... (above input/expected lines)
• -func:someMethod2
• ... (above input/expected lines)

To execute a function name, or create a new object to a class, you can use eval(className), someMethod1[inputParam], etc. Though eval is not recommended, I use it as it is test framework which is not the production file. You will better ways than eval though if that is a concern.

After using several test frameworks, found this text file testing, by far most convenient for some special cases. (No need to format in JavaScript, JSON, etc.)

If you need, you may ignore that start with #, or //, or all blank lines.

So, I wrote my own framework that works this way.

• If you know a test framework that can read above format for *.test.txt, do comment below.

• Ping me if you need my code, will share via GitHub.

As @RichardMatsen mentioned, you can use wrap function to get the element obtained from then.

Cypress docs mentions the usage of wrap on Elements as :

Wrap elements to continue executing commands

So all you need to do is :

cy.wrap($input).type('Input Text')

Update: This isn't solid. I've just done some refactoring and it seems that even this solution is flawed. It is possible for the redirect to happen in between cypress visiting the page and triggering the cy.wait so the test ends up waiting for something that has already happened. The below might still work for you depending on when your redirect is triggered, but if it's triggered on initialisation, it appears this will not work.

Not really loving this solution as the redirect still happens (I haven't found a way to cancel it), but it at least tests that the redirect happens, and allows me to check the query:

cy.intercept({ pathname: `/sessions/new` }).as(`loginRedirect`)

cy.visit(`/dashboard/`)

cy.location().then(($location) => {
  cy.wait(`@loginRedirect`).then(($interceptor) => {
    const { query } = urlParse($interceptor.request.url)
    expect(query).to.equal(`?token=true&redirect=${$location.href}`)
  })
})

Note: route2 changed to intercept in v6.

To answer straight, opening/ peeking the direct declaration of custom commands is not supported (May be, some one can correct if this supports). I would usually follow grouping of custom commands in separate files. For instance,

File: cypress/support/sample_command.ts

/// <reference types="Cypress" />

import * as PageElements from "../resources/selectors.json";
import * as Pages from "../resources/urls.json";

let xml: XMLDocument
let data: HTMLCollection

Cypress.Commands.add(
  "getWorkflowXML",
  (wfPath: string): Cypress.Chainable<HTMLCollection> => {
    var url = Cypress.env("url") + wfPath;

    return cy.request({
      log: true,
      url: url,
      auth: {
        user: Cypress.env("userName"),
        pass: Cypress.env("password")
      }
    }).then(response => {
      expect(response)
        .property("status")
        .to.equal(200);
      xml = Cypress.$.parseXML(response.body);
      data = xml.getElementsByTagName("java");
      return data;
    });
  }
);

declare global {
  namespace Cypress {
    interface Chainable {
      /**
       * Get Workflow XML through XHR call
       * @memberof Cypress.Chainable
       * @param wfPath
       */
      getWorkflowXML: (wfPath: string) => Cypress.Chainable<HTMLCollection>;
    }
  }
}

Then, in the the cypress/support/index.js file I would import the command file,

import './sample_command'

This way gives me better traceability, instead of declaring all the commands straight under index.d.ts.

Reference:

1. https://docs.cypress.io/api/cypress-api/custom-commands.html#Syntax
2. https://github.com/cypress-io/add-cypress-custom-command-in-typescript

Run the tests from products list, and build the selector from it (since they have the same form)

const products = ['shoes', 'apparel', 'accessories']
it.each(products)(`verifies the main product groups (%s) and filters`, (product) => {

  const productTab = `[data-cy="main-group-tab.${product}"]`
  cy.get(productTab)
    .click();

  availabilityPage.productGroups()
                  .should('be.visible');

  availabilityPage.searchBar()
                  .should('be.visible');
});

You should read the page called Introduction to Cypress from the Official documentation, or more generally everything under the "Core Concepts" menu. Most of these topics and concepts are explained there.

Command yields

Your assumption is correct, if you need the previous subject you need to use then since Cypress is async and doesn't return the subject. Instead it yields it. This is stated as a core concept of subject management:

Cypress commands do not return their subjects, they yield them. Remember: Cypress commands are asynchronous and get queued for execution at a later time. During execution, subjects are yielded from one command to the next, and a lot of helpful Cypress code runs between each command to ensure everything is in order.

The subject management section shows yielding examples:

Some methods yield null and thus cannot be chained, such as cy.clearCookies().

Some methods, such as cy.get() or cy.contains(), yield a DOM element, allowing further commands to be chained onto them (assuming they expect a DOM subject) like .click() or even cy.contains() again.

Each command yields something different. You can check this in the documentation for each command. For example, cy.children's yield section states that it returns a DOM element.

Technically you doesn't even need to add cy. before each command, since all of them return cy making every command chainable. Usually you only need to use .cy at the start of a command chain (like in the beginning inside a then block). This is more of a code style question.

Command execution

When you run the 3 cy.get lines the commands themselves are not going to be executed, they are just going to be added to a queue by Cypress. Cypress will track your commands and run them in order. Each command has a timeout and will wait for the command condition to be satisfied in that time frame.

As the Commands Are Asynchronous section states:

Cypress commands don’t do anything at the moment they are invoked, but rather enqueue themselves to be run later. This is what we mean when we say Cypress commands are asynchronous.

Technically I should cite the whole page of the documentation because it is really well structured, concise and detailed with a lot of example code. I highly recommend reading it.

Summary

In short, with cy. calls you queue up commands to run for Cypress. If you need to run your own synchronous code, or need the yielded subject you should add a .then() after the Cypress command you would like to run that code. You could write all your consecutive commands in a .then() but it is unnecessary, you just recreate the JS then Christmas tree of doom AKA the callback hell. So only use then if you need the yielded subject of the previous command or want to inject synchronous code. Of course, after some synchronous code (like an if condition) you need to call cy. again and they will be queued up inside that then. Whether you add your remaining cy. commands inside the then or one or more levels above, depends on if you need to work on top of the stuff happening inside the given then block or how you prefer to style your code. Here is an example from the docs modified for demonstration:

it('test', () => {
  cy.visit('https://app.com')
  // these lines will be queued up and will be run by Cypress in order
  cy.get('ul>li').eq(4)
  cy.get('.nav').contains('About')
  // we want to use the .user field's value
  cy.get('.user')
    .then(($el) => {
      // this line evaluates after the .then() executes
      let username = $el.text()
      // synchronous code to decide which commands to run (queue up)
      if (username) {
        // "queue up" other commands
        cy.contains(username).click()
        cy.get('ul>li').eq(2)
      } else {
        cy.get('My Profile').click()
      }
    })
  // command that doesn't depend on data inside the `then` block
  cy.get('.status').contains('Done')
})

I understand the pain. But to my best knowledge the auto-scan feature of cypress takes care of 're-run' of the tests as you update them. In other words, you launch the test only once using cypress open command and every time you update a test or tests, cypress UI will auto-refresh to fetch latest test code. If you changes made in a file that is being executed, then the active run will re-run automatically.

This feature is enabled by default, but for some reason is not working, check your env.json file and see below line points to true. For further reading refer cypress documentation

{
   watchForFileChanges: true
}

Coming to the injecting code from browser part, I don't think that is an option with cypress.

In cypress, first() is a command that will be chained to .get() and retry for that whole selection until timeout. That is why you can't really obtain the native element from it.

You can however yield the command, and access the element inside .then() by passing a function to it.

For example, from the Cypress documentation on this EXACT question:

cy.get('.foo').then(($el) => {
  const el = $el.get(0) //native DOM element
})

In the Cypress Docs there are two ways described how you can handle those JSON files from the fixtures folder: https://docs.cypress.io/api/commands/fixture#Examples

1. Option

Load your testdata.json using cy.fixture():

cy.fixture('testdata.json').as('testdata');

2. Option (my recommendation)

In your login.spec.js you can import all relevant json files from your fixtures folder:

import testdata from '../fixtures/testdata.json';

You can then directly use them as follows to for example use the username and password for the first user:

  it.only('TC03 - Login with valid data as subscriber', () => {
    cy.login(testdata[0].username, testdata[0].password);                            
    cy.title().should('equal', 'Home');
    cy.logout();
  })