Forum Discussion

thePantz's avatar
thePantz
Contributor
5 years ago

Prompt before executing on a specific environment

I've created a beforeRun event to prevent mistakenly executing a test on my production environment like so:

 

import javax.swing.JOptionPane;

def env = testRunner.testCase.testSuite.project.activeEnvironment.name

if (env == "Production")
{
	answer = JOptionPane.showInputDialog(null, "Warning, you're about to execute in PRODUCTION. \n\nProceed? \n\nType \"Yes\" to continue or click Cancel to abort.\n\n", "Input", JOptionPane.WARNING_MESSAGE);

	if (answer.toLowerCase() != "yes")
	{
	   testRunner.cancel("Production Run aborted due to user input.")
	}
}

The issue is I can get around this easily if I run an individual step as the beforeRun step only looks at the whole test case being run. I've tried doing this at the beforeStep event but then I am prompted for every step... 

 

Has anyone tried doing something similar? I'm curious if there is a better solution that I'm missing.

  • richie's avatar
    richie
    5 years ago
    Hey @thePanz,

    I don't know if this approach would be too much rework for you, but an approach nmrao suggested to me in regards to environmental config/environment switching might help ensure you don't execute on the wrong environment.

    Rao suggested that i create a single properties file for each environment....1 for dev, 1 for test, 1 for pre-prod, 1 for prod, etc.

    Essentially before executing any tests, i load in a specific properties file, which loads in all my environmental variables setting them as project level custom properties.....mostly i work in dev and test, but the important point being that because you have to load in the specific file to switch to a different environment and i tend to execute in prod infrequently, this approach helps handle the risk of executing in prod or pre-prod by accident. Its obviously not foolproof, but because i always load in a properties file before each execution (and i tend to execute im dev and test mostly) its part of my process now to pick the correct file so its very unlikely i'll execute my tests in the wrong environment.

    Perhaps this approach would help you too? All cred goes to Rao....he suggested this approach and its great for a number of reasons....i use this approach for every new project i work on now.

    Cheers,

    Rich
  • nmrao's avatar
    nmrao
    Champion Level 3
    This will be hindrance or obstacle to achieve automation.
    • thePantz's avatar
      thePantz
      Contributor

      My concern is that I will run my tests against the wrong environment while I'm developing my tests. I can easily disable this event when we run the whole suite

      • richie's avatar
        richie
        Community Hero
        Hey @thePanz,

        I don't know if this approach would be too much rework for you, but an approach nmrao suggested to me in regards to environmental config/environment switching might help ensure you don't execute on the wrong environment.

        Rao suggested that i create a single properties file for each environment....1 for dev, 1 for test, 1 for pre-prod, 1 for prod, etc.

        Essentially before executing any tests, i load in a specific properties file, which loads in all my environmental variables setting them as project level custom properties.....mostly i work in dev and test, but the important point being that because you have to load in the specific file to switch to a different environment and i tend to execute in prod infrequently, this approach helps handle the risk of executing in prod or pre-prod by accident. Its obviously not foolproof, but because i always load in a properties file before each execution (and i tend to execute im dev and test mostly) its part of my process now to pick the correct file so its very unlikely i'll execute my tests in the wrong environment.

        Perhaps this approach would help you too? All cred goes to Rao....he suggested this approach and its great for a number of reasons....i use this approach for every new project i work on now.

        Cheers,

        Rich