Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blockHosts test configuration override failing to apply #21151

Open
cbourdage opened this issue Apr 20, 2022 · 18 comments
Open

blockHosts test configuration override failing to apply #21151

cbourdage opened this issue Apr 20, 2022 · 18 comments
Labels
E2E Issue related to end-to-end testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. type: bug

Comments

@cbourdage
Copy link

Current behavior

Hello, I've been troubleshooting some strange behavior when leveraging the blockHosts configuration value and overriding the value with the Test Specific Configuration options.

Steps/setup:

  1. blockHosts entry is added to the cypress.json configuration file as a string value (also tried an array with single string)
  2. added an override for a test suite to set the blockHosts entry to null (the default) describe('my suite', {blockHosts: null}, () => {});

Current setup:

// cypress.json
{ "blockHosts": "*.pendo.io" }

// integration/my-suite.test.js
describe('my suite', {blockHosts: ''}, () => {});

The specific my suite test suite continues to block requests to pendo.io.

What I've identified thus far:

  1. config is set properly (confirmed the settings GUI)
  2. logged the Cypress.config() value and confirmed that blockHosts is mutated to be an empty string
  3. The x-cypress-matched-blocked-host gets set with the original blockHosts value

Screen Shot 2022-04-20 at 9 50 45 AM

I have tried with various different values for the blockHosts and also tried using the Cypress.config API directly but experienced the same behavior. From my understanding the blockHosts configuration value is not one of the read only configuration options.

Desired behavior

When providing blockHosts as a configuration value for a test suite, it should override the current blockHosts value and the cypress test should respect the new blockHosts value. This same override should be applicable using Cypress.config('blockHosts', '')

Test code to reproduce

cbourdage/cypress-test-tiny#1

Screen Shot 2022-04-20 at 10 34 12 AM

I have been able to replicate this in 2 repos now so you should be able to use any existing tests to try to override the blockHosts configuration option.

Cypress Version

9.3.1

Other

No response

@jennifer-shehane
Copy link
Member

blockHosts should override the config via a test config override. Looks like a bug. I'm not sure that we have tests for this internally (couldn't find them quickly).

@Joelasaur
Copy link

I can confirm I'm seeing the exact same issue. We found a bug in our app that requires us to test the adblocker user experience, and configuring blockHosts works great for this usecase - except we don't want to set this blockHosts value globally. Right now to solve this we would have to configure two separate json files to be passed in to two different cypress run commands with the --config-file flag, just to support this one test. We'd rather not have to upend our CI yaml for this single test but would like the coverage. Looking forward to a fix and/or workaround.

@njday
Copy link

njday commented Jun 28, 2022

Im having the same problem with this on v9.7.0

Is there any update on this issue?

@cupcakepanda89
Copy link

I'm on v10.4.0 and have similar issue, blockHosts seems not working correctly.

@GregoryVds
Copy link

I am on v.10.8.0 and I can confirm this issue is still present as well 😞

@ecclesm
Copy link

ecclesm commented Oct 13, 2022

Seeing this issue in v9.6.0

@kamilmoskal
Copy link

bump

@jeroenburgers
Copy link

This is still an issue in 11.2.0. I was hoping it was fixed by #24257, but that was only for the default config. When you override the blockHosts in your test, there is nothing happened.

image

image

@pgoforth
Copy link
Contributor

Seems that the config options never take because blockHosts is in the server context config....which is static unless the server restarts. Ergo, the server restart is never triggering, or the config in the context is never being updated between tests.

@nagash77 nagash77 added routed-to-e2e E2E Issue related to end-to-end testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. and removed routed-to-e2e labels Apr 19, 2023
@emilyrohrbough
Copy link
Member

@pgoforth You are correct - this seems to be incorrectly marked as a configuration that can be override at the test/suite level but its updated value will not take effect if updated at run-time. The bug here seems to be that this was incorrectly flagged as configurable at the test/suite level.

@pgoforth
Copy link
Contributor

@emilyrohrbough It's one thing to fix the documentation to align with functionality, but it would seem that any config parameter used inside packages/proxy would not be able to be changed at test time. The feature I'm working on (although would not require it) would greatly benefit from having test/suite level config updates inside packages/proxy. Is there a current methodology that can be used to achieve this? Is there an outstanding feature request for it? Either way, I feel compelled to work on it (since it would expedite my feature) and would like to make sure I am attacking the problem from the proper vector.

@JonathanSTH
Copy link

@emilyrohrbough @jennifer-shehane @brian-mann any word on this?

@cupcakepanda89
Copy link

any update on this issue

@rforster-dev
Copy link

Any update on this? Keen to use this functionality instead of having to create a separate config file for a select number of spec files that need to have an alternative list of blockHosts!

@rforster-dev
Copy link

rforster-dev commented Jan 4, 2024

If anyone is reading this, and wondering how i've overcome this...

// cypress/support/blockHosts.js

const defaultBlockHosts = [
  //default array of regex urls to ignore
  '*google-analytics.com*',
];

const alternativeBlockHosts = [
  //alternative array of regex urls to ignore
  '*google-analytics.com*',
  ...
];

export const blockUrls = (useAlternative = false) => {
  const blockHosts = useAlternative ? alternativeBlockHosts : defaultBlockHosts;

  blockHosts.forEach((host) => {
    // Intercept each entry and block the URL
    cy.intercept(host, (req) => {
      req.destroy();
    });
  });
};
// cypress/support/index.js
`const shouldIgnoreSpec = (specFileName) => {
  // Specify the folder pattern to ignore
  const patternToIgnore = /path/to/ignore/;

  // Check if the spec file name matches the pattern to use the refined/lite list
  return patternToIgnore.test(specFileName);
};

beforeEach(() => {
  const specFileName = Cypress.spec.relative;

  if (shouldIgnoreSpec(specFileName)) {
    blockUrls(true); // Use the default block hosts
    return;
  }
  blockUrls();
});

So in this example what i'm doing is, i'm setting up two arrays of URLs to block. There is a default list, and then a lite list.

Before every spec is ran, if the spec file is within the folder in the pattern, it will use the refined list, otherwise, it will block the requests by default.

This is a bit messy, but should be sufficient until this is resolved. I want to point out as well that in the docs it clearly states that blockHosts is able to be overriden

https://docs.cypress.io/guides/references/configuration#Test-Configuration

image

@JonathanSTH
Copy link

Will give this a shot in the near future. Thanks for the assistance.

@XavierDupessey
Copy link

Hello! Any news about this feature? Thanks :)

@XavierDupessey
Copy link

@rforster-dev unfortunately, the code you shared does not work for all cases, e.g. requests initiated by <script> tags

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E2E Issue related to end-to-end testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. type: bug
Projects
None yet
Development

No branches or pull requests