Reusing Tests Across Different Environments
Often times Ghost Inspector users have multiple instances of their service running at different URLs for different purposes. They may have the production instance at http://www.yourservice.com
, a staging instance at http://staging.yourservice.com
and a development instance at http://dev.yourservice.com
. Perhaps they use a branching scheme, like http://[branch-name].yourservice.com
, to test different code. Companies have all kinds of unique setups.
We have a few different options available for handling this: the first option allows you to override the start URL of your test(s) when you trigger a test. This is handy for individual tests, or if all the tests in your suite start from the same URL. If you need more flexibility, then variable(s) can used in the start URL and a value can be assigned to the variable(s) when triggering. We've included details for each below.
Table of Contents
Overriding the Start URL
The default start URL of every Ghost Inspector test is set in the test’s details under Settings > Browser Access. Alternatively, this can be left blank and set at the suite level under Settings > Test Defaults in the the suite. **However the start URL of tests and suites can be overridden on the fly with both our application and our API.
When using the API, there is a startUrl
parameter available that overrides the test’s start URL and lets you execute it on any URL you choose. This can also be done for an entire suite of tests. The API URL to trigger a test will look something like this:
https://api.ghostinspector.com/v1/tests/{{testId}}/execute/?apiKey={{apiKey}}&startUrl=https://custom.starturl.com
startUrl
parameter needs to be “URL encoded” if it contains characters like ?
or &
.You can also easily override start URLs when triggering tests or suites in our application using the “Run with Custom Settings…” option accessible in the “More”; dropdown menu at the top of the page.
Variables in the Start URL
The second option works in a very similar way to the one above. However, instead of overriding the whole start URL of the test(s), variables are used in the start URL and custom value is assigned to that variable when triggering. Our system uses double curly brace notation {{ }} to specify variables within a string, and they can be used within the start URL of your test(s) and suite(s).
Default values for these variables can be set up in the suite under Settings > Variables. If you set your start URL to https://{{subdomain}}.mycompany.com/login/
, you would likely want to add a “subdomain” variables under Settings > Variables in your suite with a default value like “staging”.
Setting variables when you trigger a test or suite is very similar to the method above of setting the start URL. When using the API to trigger a test or suite, you simply pass the value in as a GET paramater. Using the {{subdomain}}
example above, the API URL to trigger a test will look something like this:
https://api.ghostinspector.com/v1/tests/{{testId}}/execute/?apiKey={{apiKey}}&subdomain=dev
This would result in the start URL becoming https://dev.mycompany.com/login/
.
You can also easily set variables when triggering tests or suites in our application using the ”Run with Custom Settings…” option accessible in the ”More” dropdown menu at the top of the page.
Testing Different Environments using Data Sources
You can combine the options above into convenient, environment-specific configurations using Data Sources. The most common way to do this is to upload single-row CSV file for each environment with custom values, for instance you could upload a staging.csv
and a production.csv
:
Now when executing, select the Data Source you would like to use for the specific environment you are targeting. This option is available through our application using Run with Custom Settings, but you can also specify the Data Source ID when using the API or the our CLI.