How to configure testing for different environments, databases, etc

Question

The application I work with needs to be tested in multiple different Unix-based environments.

Currently we have things like application paths/URLs, user logins, and test data hard coded so we have to edit files to switch environments.

How can I improve on this? Ideally I would like to be able to switch the test code to a different environment without needing to edit code.

Answer 1

Use environmental variables, e.g.

$>
$> environment='UAT'
$>

You will need to export them to make them available in other processes, e.g.

$> export environment='UAT'

You can then refer to it with $environment in shell scripts, ENV["environment"] in ruby, etc.

You can use this approach to let you set

• environment name
• login credentials
• database credentials
• environment specific values

without having the values in your codebase at all

Answer 2

In addition to Michael's answer, if you have a continuous integration or continuous deployment environment, you can configure your environment to set different values in the test config file to match the target run-time environment.

This approach is similar to the environmental variable approach, but is operating-system neutral, managed by the build/deployment system, and allows you to refer to values like:

• environment name
• login credentials
• database credentials
• environment-specific values

by a variable/constant name in your code or config files, and let the build/deployment system handle the rest.

The one thing that needs to be remembered is that whenever you add a new environment, you may need to tweak the build/deployment system to handle it - although if you keep as many of the variables as possible similar if not identical the need for adjustment is minimized (e.g. an environment for these purposes would be an operating system/test-staging-production pairing and all application paths, database credentials etc. would be the same across all systems in that environment).

Answer 3

You can use an external file such as a properties file to store environment variables. Your automation framework can read from the file to determine which base URLs and authentication tokens you require for that specific environment. Your property file can have things like:

ENV=STAGING
USER=TOM
TOKEN=sf234dalkjasrsfdds832
DB=MY_DB

You can change this file when you want to run different environments. If you have a continuous integration system like Jenkins running your automation. You can have Jenkins rewrite this file before running your automation suite. You can use a parameterized build to pass in the environment from a drop down menu or something. Your automation framework should read from this file to dynamically determine which variables to use.