WebElement.click()

Lets assume that we’re in charge of testing the application that utilizes environment variables in its business logic. Say it would be a trading bot that expects the exchange address set in environment variable EXCHANGE_ADDRESS. If we approach to the test planning from the prospective of classical theory, we’ll prepare the set of test data, considering all the aspects of the algorithm that is used by our trade bot when it attempts to connect to the exchange (not forgetting about negative scenarios like invalid syntax of the address, or address that is behind authorization mechanism, or the address that returns to the client some error code). We will approach with that and we’ll be right. By setting again and again new values for the environment variable and restarting our trade bot, we’ll cover all the scenarios we have planned. We can do that by describing corresponding instructions (which set the values for variable and restarting trade bot) in some script file (like .bat file for Windows or shell script for *nix-like systems). But what if we want to have several bots running in parallel and running targeting different exchange addresses?

All operating systems support the mechanisms which allow the processes to summon other processes. You can check that using any process monitoring tool that your OS should have. As the result you should observe the process tree which means that all the process are in some hierarchical relationships with other processes. At the same time the context of the parent process is propagated to the child process. The context includes the environment variables as well.

For example if you open Windows command line and execute the command set, you will observe the list of some variables which are assigned with some values. Lets pick some variables to be our test subject. I have the variable named PUBLIC in my list and I’m going to use it for my experiments. In order to query the value of only that my variable we can use the command set PUBLIC. Great! We obtained its value. Lets now change the value (no panic - it will be changed for only the current process, and as we will see later - for child processes as well, but it will not impact parent processes). Execute set PUBLIC=%PUBLIC%-changed.By the way, wrapping the variable name with % is a more correct way to query the variable value in your script. You can change set PUBLIC to echo %PUBLIC% with almost the identical result. It will differ only with that set returns the name-value pair while the latter one returns just the value.

Lets now check what value does the variable have after we have changed it. Moreover we now know how to do that. We can see that it has been really changed. Lets now execute the command start cmd.exe. The command will open another command line window. Check the value of our variable in that new window. It turns out that the value is equal to what we have changed the original value to. That means the context of our original process was propagated to the child process.

Lets now get back to our first command line. Change the value of our test variable again, but this time to something different from what we set previous time. Repeat summoning of new command line window. It is easy to make sure that that our new summoned command line process have the variable value corresponding to our latest change.

Okay, so by the moment we should have three processes each handling own command line. One process is a parent and two other processes are its children. Both the children have their own PUBLIC variable storing different values. Now you can execute two trade bots each from different command lines (of course considering that we have to map approach with one my hypothetical example to another my hypothetical example), so that your test cases can be extended which parallelization aspect.

By the way, in Linux OS (as well as in Unix one) everything works using absolutely the same principles. The only commands are different. For example, if you want the variable value propagated to child process in your Linux script, you should use export command (e.g. export EXCHANGE_ADDRESS=http://blahblah.blah).

Except of manual testing practices, environment variables are widely used in automated testing. Often to make one’s code less coupled with execution environment, test developers delegate different configuration aspects to the people who are in charge of managing test execution environments (also often it happens that they are the same people, however it is another story). Such the approach allows to integrate tests into CI (Continuous Integration) processes more effectively where test run is only one step in the long chain which is managed by some master process.

Below I’ll list some typical configuration entities which are usually set in environment variables.

In general, any information that might be potentially relevant to only some particular environment/environments (but not for all the environments) - is the candidate for applying described approach.

Still have questions? Ask them here. I will try to extend the article with missed points leaning on your feedback.