You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 31, 2023. It is now read-only.
I think my idea basically boils down to whether it makes sense to have this plugin be advanced enough to conveniently handle multiple environment variables as opposed to just the ENVIRONMENT? So one could easily do things like:
import { onlyOn } from '@cypress/skip-test'
onlyOn('feature1', () => {
describe("This spec", function() {
it('Requires feature to be present', function(){
//test here
});
});
});
with npx cypress run --env FEATURE_FLAG=feature1
Also, a question that just comes to mind:
Is doing cy.onlyOn('electron').onlyOn('mac'); equivalent of saying run this test only if on 'electron' AND 'mac', or 'election' OR 'mac'? Similarly is the below when 'mac' AND 'chrome' or 'mac' OR 'chrome'? (I know the readme implies it is both at the same time, but I wanted to double check still):
I think this could have bearing on whether making an environment variable that is actually an array of variables, is already supported in another way. Or maybe one could do something like npx cypress run --env FEATURE_FLAG1=feature1,FEATURE_FLAG2=feature2,ENVIRONMENT=something and it will just work, if the plugin supports using multiple env variables that you choose for it to pay attention to. At the very least, one could do onlyOn(feature1 === 'feature1' && feature2 === 'feature2'); and maybe that is sufficient already?
We are still kind of figuring out what we will need and how we may want to do it. It isn't like we have tons of feature flags we need to manage constantly, but enough that we want to think about it before too long. So if we end up extending the skip-test package, I'll be happy to submit a PR here to see if it makes sense to have it generally available. Thanks for any thoughts and ideas on this.
The text was updated successfully, but these errors were encountered:
Well, not that this is a hot topic or anything, haha. But just in case, definitely don't do anything with this capability/request on my accord. I have a feeling it will never be needed where I thought it might be.
I think my idea basically boils down to whether it makes sense to have this plugin be advanced enough to conveniently handle multiple environment variables as opposed to just the ENVIRONMENT? So one could easily do things like:
import { onlyOn } from '@cypress/skip-test'
onlyOn('feature1', () => {
describe("This spec", function() {
it('Requires feature to be present', function(){
//test here
});
});
});
with npx cypress run --env FEATURE_FLAG=feature1
This can be achieved with CYPRESS_FEATURE_FLAG=feature1 npx cypress run and:
I think my idea basically boils down to whether it makes sense to have this plugin be advanced enough to conveniently handle multiple environment variables as opposed to just the ENVIRONMENT? So one could easily do things like:
with
npx cypress run --env FEATURE_FLAG=feature1
Also, a question that just comes to mind:
Is doing
cy.onlyOn('electron').onlyOn('mac');
equivalent of saying run this test only if on 'electron' AND 'mac', or 'election' OR 'mac'? Similarly is the below when 'mac' AND 'chrome' or 'mac' OR 'chrome'? (I know the readme implies it is both at the same time, but I wanted to double check still):I think this could have bearing on whether making an environment variable that is actually an array of variables, is already supported in another way. Or maybe one could do something like
npx cypress run --env FEATURE_FLAG1=feature1,FEATURE_FLAG2=feature2,ENVIRONMENT=something
and it will just work, if the plugin supports using multiple env variables that you choose for it to pay attention to. At the very least, one could doonlyOn(feature1 === 'feature1' && feature2 === 'feature2');
and maybe that is sufficient already?We are still kind of figuring out what we will need and how we may want to do it. It isn't like we have tons of feature flags we need to manage constantly, but enough that we want to think about it before too long. So if we end up extending the skip-test package, I'll be happy to submit a PR here to see if it makes sense to have it generally available. Thanks for any thoughts and ideas on this.
The text was updated successfully, but these errors were encountered: