Would there be a disadvantage on using Cypress.removeAllListeners on these 2 events => could it potentially remove events that Cypress using?

+ is there a cleaner way to access context than this.mocha.getRunner().test.ctx.consoleLoggingTestConfig inside the callbacks of window:before:load and command:end?

@User What is the end goal of what you are trying to write?

@User The end goal is to be able to do something in the line of https://www.npmjs.com/package/cypress-fail-on-console-error, but with: * Cypress logging of what the calls were * A sort of global configuration (like registering which console levels are to be checked + excludedMessages per level) , but additionally also a per test configuration that extends on the global one I have something that seems to be working now, although some of the things are a bit... hacky it feels to me as I use the mocha test context (mostly because not all events seem to have straight access to the context through

this

). I could send you the full code I have now if you'd like (might be a bit long here)

Have you already verified that the baseUrl the Config resolves with matches the server that is up and running? Ah, I see the baseUrl you pass in is just greyed out, so that should be simple. I can't think of anything else though...

hey guys - im new to cypress and front end testing in general, and had a question about how to organize some of my testing. Example. I have one test to ensure that a user can login, click in a search box, search a file name, and a specific file returns. Now, I am wanting to write a separate test to ensure that a user can download a file. In order to do so, every step from the previous test needs to be completed. Should I rewrite those steps in my second test? Or call that test from before inside my second test? Does this make sense?

There’s a great article about how to organize your tests with cypress especially if you’re doing Cypress Dashboard in the future.

@gray-kilobyte-89541 heyo. Trying to find the right article

This is the one for how to write multiple steps within the same test instead of one-liner assertions

You can also take the approach of shortcuts, usually with API requests or accessing state managers, so you effectively skip the UI for steps you already have tests for. Cypress really shines in this approach. App actions is one term given to this. See https://glebbahmutov.com/blog/realworld-app-action/ and https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/

Though for the record, I'm also a fan of larger tests or user flows for E2E testing. When you want to test lots of little things about functionality, that is what led me to component testing.

take a look at https://slides.com/bahmutov/testing-mistakes#/5 and https://glebbahmutov.com/blog/split-spec/ and https://docs.cypress.io/guides/core-concepts/writing-and-organizing-tests

awesome. I'll give these articles a read! thanks guys.

was trying to swap out manual login to auth 0 with something that will do it automatically but I can't seem to find out what belongs in this callback?code=state=

Cypress.Commands.add('login', (email, password, overrides = {}) => {
  Cypress.log({
    name: 'loginViaAuth0',
  });
  const options = {
    method: 'POST',
    url: Cypress.env('auth_url'),
    body: {
      grant_type: 'password',
      username: email,
      password: password,
      audience: Cypress.env('auth_audience'),
      scope: 'openid profile email',
      client_id: Cypress.env('auth_client_id'),
      client_secret: Cypress.env('auth_client_secret'),
    },
  };
  cy.request(options)
    .then((resp) => {
      return resp.body;
    })
    .then((body) => {
      const { access_token, id_token } = body;
      const auth0State = {
        nonce: '',
        state: id_token
      };
      cy.visit(`/callback?code=${auth0State.state}state=${access_token}`,{
        onBeforeLoad(win) {
          win.document.cookie = 'auth0.is.authenticated', 'true';
          win.document.cookie = '_legacy_auth0.is.authenticated', 'true';

        }
      }).as('login');
    })
    cy.wait('@login'. {timeout: 60000});
});

In an E2e test, we're trying to test a table's sorting, by checking the values in the rows (and then clicking a certain row). For this we had:

cy.get('.vl-data-table tbody').find('tr').contains('123456798').click();

Which worked fine, until we turned on throttling. Now we made some changes to instead do:

cy.get('.vl-data-table tbody').find(`tr:contains('123456789')`).click();

I guess this is because the table updates more slowly now, and the

.find('tr')

actually returns old results, and does not get retried? (meaning the

.contains'

get called on old values) Is the solution we went for here the way to go (it feels a bit iffy), or is there another way this kind of thing should be done?

Guessing this: https://docs.cypress.io/guides/core-concepts/retry-ability#Only-the-last-command-is-retried

Probably the

tr

successfully finds the results before the update. It has no way of knowing what old/new are. You can do a

js
cy.get('.vl-data-table tbody').should(($tableBody) => { /* expect(....).to.contain(...) */ }

The content inside of should will be retried until the expectation passes or fails. So you can get the TR over an dover until it contains the right stuff

Quick q: what do you use to selectively run tests, aka “tag” tests to run and how do you do that?

Or you can do a {timeout: 1 billion years}

So this will look at that tbody or tr for a set amount of time until it contains what you want

This is bad practice but I just import the test files I want and run that file

And just like jest if your files are numbered or even the describes or context are numbered then it will run them by the numbers

Makes sense yeah. Ended up makes the queries itself more specific throughout our test files, but definitely something we should pay more attention to

Not sure if that was a general "what ya'll using", or if someone was targeted 😆: We pretty much always add

.only

throughout our `describe`/`it`s for that, if that's what you mean.

Hello everyone, I am experiencing an issue with

cy.getCookie()

where it's timing out even though based on the documentation, it shouldn't. Anything I could be possibly missing?

I created this issue on Github https://github.com/cypress-io/cypress/issues/16297 . If anyone can help, it'll be super appreciated.

hey guys! i encouraged a friend of mine to try out Cypress, so she attempted to automate a simple google image search. An issue occurs that I am unable to help her with, but thought some of you all may know whats going on. Whenever she hits the url for image results in google, the page flashes as loaded, and then goes blank. This occurs whether she clicks on the images tab, or directly calls cy.visit with the url.

this isnt a real project, so it isnt pressing.. but i was curious what is the culprit. I was able to replicate the issue by calling cy.visit(

https://www.google.com/search?tbm=isch&q=puppy

)