In this quick start tutorial you will get up and running with a simple test plan. Later tutorials will go deeper into features of the Testground SDK and how to use it to simulate P2P network environments. For now, let's get your hands dirty writing your first test plan.
Following these steps you will create a test plan along with all supporting files.
Let's dive right in, and we'll explain as we go.
Go through the Getting started page and follow the instructions in order to install Testground.
Testground stores plans in the
$TESTGROUND_HOME directory. This directory is created for you in your
home directory, but if you prefer to store plans in another location, you can adjust the location using the environment variable.
# OPTIONAL - adjust TESTGROUND_HOME, default is ~/testground$ export TESTGROUND_HOME=/path/to/testground/home# create your first test plan$ testground plan create --plan=quickstart[...]test plan created under: $TESTGROUND_HOME/plans/quickstart# Bingo! A new, barebones templated Go plan will have been created# under $TESTGROUND_HOME/plans/quickstart; explore the source!
$ testground daemon
$ testground run single --plan=quickstart \--testcase=quickstart \--runner=local:docker \--builder=docker:go \--instances=1
This will start a flurry of activity that will leave you wondering "what gives? isn't this a simple little hello world program?".
Well, Testground provides a few features that aren't exercised by this example. Continue with this tutorial to learn more about writing test plans.
Here is a list of what you have just witnessed:
testground-build network is created.
goproxy Docker image is downloaded and a container is started.
Your code is copied into a new Docker image.
Your code is compiled, and added to a new Docker image.
Several supporting containers are downloaded and started:
testground-sidecar - the Testground service responsible for adjusting the test plan networks.
testground-redis - the Testground synchronization service backend.
influxdb - runtime metrics from test plans.
grafana - dashboards for monitoring test plans and infrastructure.
A number of containers are created based on your image (
--instances controls this).
Your code is executed in each of the containers.
outputs of the test run are collected for analysis.