How to use smokeTestDockerImage method in Cypress

The problem is that you are trying using variable set between test cases when it's already reset to store token you need either use global variable (not advised), or create some login command that will be called before you need access to token. For example:

Cypress.Commands.Add('login', (userName, password) => {
  cy.request({
      method:'POST', 
      url:'https://odms.baitussalam.org:8445/api/v1/auth/login',
      body: {
        userName,
        password,
      }
    })
    .as('loginResponse')
    .then((response) => {
      Cypress.env('token', response.body.accessToken); // either this or some global var but remember that this will only work in one test case
      return response;
    })
    .its('status')
    .should('eq', 200);
})

Then whenever you need you login user before using Cypress.env('token').

For example:

describe('testing token', () => {
  beforeEach(() => {
    cy.login();
  });

  it('test request', () => {
    const token = Cypress.env('token');
    const authorization = `bearer ${ token }`;
    const options = {
      method: 'GET',
      url: `https://odms.baitussalam.org:8445/api/v1/qurbani-representative`,
      headers: {
        authorization,
      }};

    cy.request(options)
      .its('status')
      .should('eq', 200);
  })
});

You can go further and override all request to add token to them like this:

Cypress.Commands.overwrite('request', (originalFn, ...options) => {
  const optionsObject = options[0];
  const token = Cypress.env('token');

  if (!!token && optionsObject === Object(optionsObject)) {
    optionsObject.headers = {
      authorization: 'Bearer ' + token,
      ...optionsObject.headers,
    };

    return originalFn(optionsObject);
  }

  return originalFn(...options);
});

then the above example would look like this:

describe('testing token', () => {
  beforeEach(() => {
    cy.login();
  });

  it('test request', () => {
    cy.request(options)
      .its('status')
      .should('eq', 200);
  })
});

Will leave this here in case it helps somebody https://github.com/javieraviles/cypress-upload-file-post-form

Second scenario (send_form_data_with_file_in_post_request_spec.js):

I want to build up the FormData myself( new FormData(), formData.append/formData.set ) and send it directly with a POST request to the backend or submit the form with the FormData I have created. For this case, the transmitted data must be in the same format as the form's submit(), which type is set to "multipart/form-data". Having a look at the MDN web docs to see how you can build a FormData: Using FormData Objects, and knowing that at this very moment (Cypress 2.1.0) cy.request doesn't support FormData (multipart/form-data) so we will need a XMLHttpRequest, the test can be performed as follows. Include the following code in your "commands.js" file within the cypress support folder, so the command cy.form_request() can be used from any test:

// Performs an XMLHttpRequest instead of a cy.request (able to send data as 
// FormData - multipart/form-data)
Cypress.Commands.add('form_request', (method, url, formData, done) => {
    const xhr = new XMLHttpRequest();
    xhr.open(method, url);
    xhr.onload = function () {
        done(xhr);
    };
    xhr.onerror = function () {
        done(xhr);
    };
    xhr.send(formData);
})

Then, in case you want to send the same form as before (form containing an excel file and other plain inputs) but build it by yourself and send it directly to the server, the test would be something like this:

describe('Testing the API', function () {

    it('Receives valid FormData and proccesses the information correctly', 
        function () {

    /*
    The reason why this test may look a bit tricky is because the backend endpoint is expecting the 
    submission of a web Form (multipart/form-data), not just data within a POST. The "cy.request()" 
    command doesn't support sending a web Form as a body in a POST request, so the test uses a support 
    command that has been created to perform a genuine XMLHttpRequest where a web Form can be placed.
    */

    //Declarations
    const fileName = 'your_excel_file.xlsx';
    const method = 'POST';
    const url = 'http://localhost:3000/api/excel_form';
    const fileType = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet';
    const inputContent2 = 'input_content2';
    const expectedAnswer = '{"msg":"X elements from the excel where successfully imported"}';

    // Get file from fixtures as binary
    cy.fixture(fileName, 'binary').then( (excelBin) => {

        // File in binary format gets converted to blob so it can be sent as Form data
        Cypress.Blob.binaryStringToBlob(excelBin, fileType).then((blob) => {

            // Build up the form
            const formData = new FormData();
            formData.set('file', blob, fileName); //adding a file to the form
            formData.set('input2', inputContent2); //adding a plain input to the form
            .
            .
            .
            // Perform the request
            cy.form_request(method, url, formData, function (response) {
                expect(response.status).to.eq(200);
                expect(expectedAnswer).to.eq(response.response);
            });

        })

    })

})

})

From the docs,

Results XML filename can contain [hash]

Also, if you check the junit reporter source, you can see how is doing it:

...
this.writeXmlToDisk(xml, this._options.mochaFile);
...

MochaJUnitReporter.prototype.writeXmlToDisk = function(xml, filePath){
  if (filePath) {
    if (filePath.indexOf('[hash]') !== -1) {
      filePath = filePath.replace('[hash]', md5(xml));
    } ...

So, you could just have:

"mochaFile": "./cypress/results/my-test-output[hash].xml"

The snowflake-sdk is a NodeJs package, so in Cypress you need to interact with it via a task.

Here's a basic connection task taken from the Snowflake docs.

cypress.config.js

const { defineConfig } = require("cypress");
var snowflake = require("snowflake-sdk");

let connectionId;

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on("task", {
        snowflake: () => {
          var connection = snowflake.createConnection({
            account: "account",
            username: "user",
            password: "password",
            application: "application",
          });

          connection.connect(function (err, conn) {
            if (err) {
              console.error("Unable to connect: " + err.message);
            } else {
              console.log("Successfully connected to Snowflake.");
              // Optional: store the connection ID.
              connectionId = conn.getId();
            }
          })
          return null
        },
      });
    },
  },
})

Test

it('Connect to snowflake', () => {
  cy.task('snowflake')
})

Without proper credentials, it produces a connection error but proves the package is working.

Unable to connect: Request to Snowflake failed.

You can achieve aliases/variables and get. The trick is that get, invoke, or similar are effectively async and you can't really effectively await cypress operations. Instead you can get the first number, parse it, get the second number, parse it, add the numbers and assert/expect:

const expectedTotal = 42;

// get element with id #num-1
cy.get('#num-1').then(($num1) => {
  // parse text to int/number
  const num1 = parseInt($num1.text());

  // get element id #num2
  cy.get('#num-2').then(($num2) => {
    // parse text to int/number
    const num2 = parseInt($num2.text());
    
    // expect/assert number total equal to some expected total
    expect(num1 + num2).toEqual(expectedTotal);
  });
});

Hopefully that helps!

I had the same question, and couldn't quite square the accepted answer with what I saw happening (in Cypress 9.2.1).

It turns out that when a .js file is given as a fixture, cypress eval()s the content of the file (actually, it uses eval-with-parentheses), and uses whatever object this results in. So it is possible to have a file user-details.js, which looks like

[{name: "Bob", age: 30 + 5}]

or even execute some "real" code:

["Bob", "Rob", "Job"].map((name, index) => ({user: name, age: 20 + index}))

or

(() => {
    const users = ....
    return users
})()

It should be noted that it's not as flexible as you might want (e.g. you cannot import code, do asynchronous things, etc), but it's more than nothing.

The question is, should you....

Quite honestly, I think this is a great way to allow making your fixtures slightly more human readable, being able to add comments, and easy conversions. And you're not bothered by JSON's comma-stictness E.g

[
  // have a single user, because blah blah
  {name: "Bob", date_of_birth: new Date(1979, 5, 3).valueOf() / 1000},
]

(Date(1979, 5, 3) is much better human-readable than some unix timestamp (even though it means 5th of June, not 5th of May....))

I fully think that the .js fixture is a good way to do this (and would be even happier if it would just import the fixture as a module and use the default export as item or something, but eval is acceptable....), as long as the thing you're producing is constant! If you want something dynamic (or, probably, something constant that takes a bit more complexity to make), you're much better of with @seth-lutske 's suggestion (meaning that in your case, the accepted answer is what you need, however I wanted to document how .js fixtures work in case someone else came by).

Having said all this, it's questionable why cypress uses an eval() here, even though the suggested way is to use window.Function(); in addition, I wonder if you want to run the risk that down the line, some other developer (which includes future-you) decides to build a system that downloads your fixtures from some external website, which means that you created a nice security hole....

It's very informative to read the github issue on Javascript fixtures (I wish I had before I dove into all this myself); if you're looking for a good workaround, see this and this comment.

As a concrete answer to the question asked, the problem is that

eval(`data = {
  email: function () {
    const currentTimestamp = new Date().getTime();
    return \`test\${currentTimestamp}@test.com\`
  },
  firstName: 'Max',
  lastName: 'Mustermann',
  street: 'Some Street',
} `)

will return exactly that object, which should be accessible on this.userDetails. Therefore this.userDetails.data points to the data-field in this object, which is undefined.

The following would work:

user-details.js:

{
  data: {
    email: function () {
      const currentTimestamp = new Date().getTime();
      return `test${currentTimestamp}@test.com`
    },
    firstName: 'Max',
    lastName: 'Mustermann',
    street: 'Some Street',
  }
} 

(or, in case you want email to be a string rather than a function:

{
  data: {
    email: (function () {
      const currentTimestamp = new Date().getTime();
      return `test${currentTimestamp}@test.com`
    })(),
    firstName: 'Max',
    lastName: 'Mustermann',
    street: 'Some Street',
  }
} 

)

You can use jquery via Cypress.$ to check if any exist.

const listItemTitle = '[data-cy-component=list-item-title]';
if (Cypress.$(listItemTitle).length > 0) {
  cy.get(listItemTitle).each(($el, index, $list) => {
    cy.wrap($el).then(($span) => {
    const spanText = $span.text();
    cy.log(`index: ` + index + ' ' + spanText);
    });
  });
}

All the code and referenced modules in index.js are loaded before your test file. So you need to refer(require) commands.js in your index.js file. You can however import commands.js module directly in your test file but then you need to include it every test file. Recommended approach is to include it in index.js file and you are not worried about explicitly refer in your test files.

The values between tags like <li>15</li> are accessed on individual element with .invoke('text').

invoke('val') is for <input> and <textarea> elements.

But if you select multiple elements, the texts will mash together

cy.get('li')                  // multiple elements selected
  .invoke('text')             // joins all text together, result is "5153045"
  .should('eq', '5153045')    // passes

In your case it's ok, but feels a little clumsy. In another scenario you can get additional white space between texts which makes it harder to compare.

You can use jQuery to extract individual texts, and they can be trimmed to make a better match when extra white-space is present

cy.get('li')                                            
  .then($els => Cypress.$.map($els, (el) => el.innerText.trim())) // uses jQuery .map()
  .should(values => {
    expect(values).to.deep.eq(["5","15","30","45"])
  })

But if your dropdown items are fetched from an API, you should put as much of the calculation as possible inside the .should() callback, because Cypress retries until passing

cy.get('li')                                            
  .should($els => {                                              // retries here
    const values = [...$els].map(el => el.innerText.trim())      // uses Array .map()
    expect(values).to.deep.eq(["5","15","30","45"])
  })