How about environment variables insertion or custom cli option processing omitting when app launching?

[tomoh1r]

What is your Scenario?

I know TestCafe could treat a configuration file, but I need complex pattern resolvement.

This issue aims to treat environment variables on Windows terminals, macOS/Linux could one liner with ENV=stg testcafe ~, but we need two steps on Windows. The issue resolves this issue.

If I construct custom teardown test process and need to run only this, I'd like to add --cleanup custom argument and it could treat this on cjs configration script.

Or, If I could add --stg or --env=ENV=stg argument, it will run stg testing, and I use --cleanup --stg will clean stg environment.

What are you suggesting?

I need a or b, I think a is easier than b

a. --env argument and modify environment variables

I could set --env ENV=stg,TASK=teardown settings, and I could use this environment variables on Configuration CJS script (.testcaferc.cjs) to switch our test behaving.

I know we (user on Windows) can set environment variables other lines, but it is easier to set values one liner, I need.

b. add feature to set custom user argument omitting setting

I know if add unregistered argument to app launch, it will be cause error to tell "no such test files", I'd like to suppress this error.

If we could set { customArgs: ["--environment", "--cleanup"] } to (.testcaferc.json), I could treat this argument on Configuration CJS script (.testcaferc.cjs) to switch our test behaving.

If customArgs conflics embded arguments, I expect it will cause error.

What alternatives have you considered?

No response

Additional context

No response

[PavelMor25]

Hello @tomoh1r,

Could you please describe your usage scenario in more detail? Specifically, what aspects depend on your customArgs or environment variables? If possible, please share a minimal example of what your .testcaferc.cjs file might look like.

[tomoh1r]

Hi @PavelMor25 , thank you for your response.

your usage scenario in more detail?

I’m looking to manage setup and cleanup cases. Sometimes, test cases need to set up data or finalize unusual data. In this case, I’d like to modify TestCafe’s behavior so that it can either run cleanup only or run cleanup before setup.

It would be great if we could control test case behavior with a simple command. This would give us more flexibility.

what aspects depend on your customArgs or environment variables?

Although we can use test meta to filter, we usually implement tests with both setup and cleanup scenarios. I want to switch the behavior to either run cleanup only or run cleanup before setup. I think test meta doesn’t fit this case because I expect this behavior to be applied within a single test, rather than being decoupled.

If I can set customArgs or environment variables, I can configure these settings in the .testcaferc.cjs file.

If possible, please share a minimal example of what your .testcaferc.cjs file might look like.

Here’s a minimal example of how we might use customArgs to switch behavior with userVariables in the test case. Alternatively, if we use environment variables, we can use process.env instead of userVariables.

const process = require('process');

const args = process.argv.slice(2);
const cleanupOnly = args.includes('--cleanup');
const cleanupOnSetup = args.includes('--cleanup-on-setup');

module.exports = {
  userVariables: {
    cleanupOnly: cleanupOnly,
    cleanupOnSetup: cleanupOnSetup
  }
};

Feel free to ask any questions.

[PavelMor25]

Hello @tomoh1r,

We have received a similar request before: the user wanted to set a project configuration that is unique for every test run by creating a new environment instance before testing. Could you please review the #8195 issue and check if the proposed workaround there can be adapted to your usage scenario?

Please let me know your results.

[tomoh1r]

Hi @PavelMor25,

My scenario involves changing test case behavior using custom or environment arguments, regardless of whether the environment is isolated. Therefore, #8195 does not apply to the case in #8269.

The issue proposes creating a new mechanism for altering test behavior. I’m not affected by this problem and believe the focus is on deciding whether or not to implement the mechanism.

The core of my idea is to block and filter test cases. I envision using flags with arguments to conditionally run or skip blocks of code. Here’s an example of what I have in mind:

const { userVariables } = require('testcafe');

test('foo', async (t) => {
  if (!userVariables.cleanupOnly) {
    // setup code
    await someSetup();

    // test case code
    await t.expect(result).ok();
  }

  // cleanup code
  await doCleanup();
});

Feel free to ask any questions.

[PavelMor25]

Hello @tomoh1r ,

Thank you for the explanation.
 

Therefore, #8195 does not apply to the case in #8269.

You can utilize Environment Variables directly in your tests. For more details, please refer to Access Environment Variables in Tests.

Does this approach cover the use case you described?