Test Automation & Environment Variables

noun_testing_3404930.png

noun_testing_3404930.png

A lot of people new to test automation get a bit confused about environment variables, which are a really important thing to understand.  So what are they?

Environment variables are, well, variables.  Just like a variable you might set in code or in a script, except they exist at the operating system or process level.  That’s why they are call “environment” variables.  They exist on all major operating systems, Linux, MacOS and Windows, with some minor differences.

The main reasons to use an environment variables, are to set some piece of information that the operating system needs to know, or to avoid hard-coding something in a script.

A really commonly used environment variable is the PATH variable.  Every command that you run in a shell (also known as a command prompt, in Windows) is a file, and the operating system needs to know where that file is stored.  When you use a UI method to access an executable there is a file that defines the icon and the location of the file, but this isn’t the case with a shell.  The operating system simply consults a list of directories stored in the PATH environment variable and checks in each directory.

You can see what your path variable looks like by printing it to a shell.  On Linux or MacOS you might do this by running the following command in a shell:

echo $PATH

The $ sign indicates that this is a variable, not just a string, and you’ll see that it prints a list of directories!  In Windows, the same principle applies, but you indicate that it is a variable by surrounding it in % signs:

echo %PATH%

So what if we want to print all environment variables?  On Windows you can just type “set”, and on Linux/MacOS you can type “printenv”.  This will show you a very long list, on Linux you can use grep to filter this, but there is no Windows equivalent on a base install.

Engineers working on a Java / Maven / Selenium project might need to consider the following:

  • Ensuring that the path includes the bin directory for Apache Maven

  • Ensuring that the path includes the bin directory for the Java installation

  • Adding the location of chromedriver to the path variable (to avoid specifying it in code).

If those items aren’t in place, you might need to add them.  The easiest way to do this is to manipulate the variables interactively in the shell.  In Linux/MacOS there are two ways to do this, you can simply do:

MY_VAR=1

echo $MY_VAR

1

Note that you don’t need the $ here when defining the variable, you only need it when you are referencing the variable.  On Windows this is again slightly different:

set MY_VAR=1

echo %MY_VAR%

1

Now, a key thing to remember, is the above commands will only influence the shell you are running the commands in.  You can influence other processes on Linux/MacOs using the export command, this will ensure that any child processes will be able to see the variables.  When you run another command (e.g. java) it will spawn a new child process.  In order for that process to see the environment variable you have just set, you must use export:

export MY_VAR=1

In Windows, this works by default, but you might want to set the variable to be visible to other shells (command prompts).  You can do this by using setx instead of set, however confusingly it has a slightly different syntax (note there is no equals sign):

setx MY_VAR 1

You might also want to append to an environment variable, the PATH variable is a good example of this as you rarely want to lose all the data already within it.  You can do this by specifying the variable inline with the variable definition, so:

export PATH=$PATH:<some new directory>

or

set PATH=%PATH%;<some new directory>

Of course, as soon as you close the shell (in Linux/MacOS), or reboot (Windows), the environment variables will be lost.  You need to use a slightly different process in order to make them persistent.

In a Windows environment, there are two types of environment variables, system and user variables.  System variables require administrator access to change, and often people don’t have that, but user variables can usually be changed.  You can do this through the control panel  In Linux and MacOS, you can usually change any variable by editing the startup script for the shell software you are using - for instance in bash you would edit ~/.bashrc.

Now you understand how to use environment variables, you might want to use them in your code.  It’s fairly common for example, for automation suites to a have a config file that defines e.g. URLs for the system under test.  Maybe, if you have multiple environments, you might want to specify the URL at runtime instead of in config.  Then, you can add them to something like a Jenkins build script, so each Jenkins job will set a different parameter.  You can easily then access environment variables from code, here’s examples for Java and Python:

Java:  System.getenv("URL");

Python:  os.environ.get("URL")

Simple, right?  Have fun!

Article written by Adam Leon Smith, CTO of Dragonfly

Previous
Previous

Quality Characteristics of Artificially Intelligent Systems

Next
Next

The 'People Challenge: Just Say No'