Getting started
Last updated
Last updated
How to install Testground, and run your first test plan
, or higher
Currently, we don't distribute binaries, so you will have to build from source.
In order to use Testground, you need to have a running Testground daemon.
$TESTGROUND_HOME
is an important directory. If not explicitly set, Testground uses $HOME/testground
as a default. The layout of $TESTGROUND_HOME
is as follows:
The first test plan that we will run is the network
test plan and the ping-pong
test case.
Configure $TESTGROUND_HOME
and copy the example network
test plan into the $TESTGROUND_HOME/plans
directory.
Run the network
testplan and the ping-pong
test case with the docker:go
builder and the local:docker
runner.
?> Make sure you have testground daemon
running in another terminal window.
?> During the first run the Testground daemon sets up the builder and runner environments. Subsequent runs will be faster.
You should see a flurry of activity, including measurements, messages, and runtime events. When the execution concludes, you will see something like:
In the local runners, all test plan run outputs and logs are stored at $TESTGROUND_HOME/data
. Collect them into a bundle with the following command (replacing 5222e5df793b
with the corresponding run ID):
Open the bundle and you will find the outputs from the test in there:
.env.toml
is a configuration file read by the Testground daemon and the Testground client on startup.
Testground tries to load this file from $TESTGROUND_HOME/.env.toml
, where $TESTGROUND_HOME
defaults to $HOME/testground
by default.
You can change the default bind addresses by configuring daemon.listen
and client.endpoint
.env.toml
The endpoint refers to the testground-daemon
service, so depending on your setup, this could be, for example, a Load Balancer fronting the kubernetes cluster and forwarding proper requests to the tg-daemon
service, or a simple port forward to your local workstation:
You can customize the number of asynchronous workers, as well as the maximum queue capacity, i.e., the maximum number of pending tasks at a moment in time. In addition, you can adjust the workers' task time execution limit. This is a handy option, if you have long-running tests
.env.toml
When using a remote runner such as cluster:k8s
, you should configure the default region:
.env.toml
The AWS configuration is also used if you push Docker images to AWS ECR from the docker:go
builder using the --build-cfg push_registry=true
and --build-cfg registry_type=aws
flags.
If you want to push Docker images from the docker:go
builder to a DockerHub registry, you can configure it.
.env.toml
The ping-pong
test case starts 2 test plan instances: one that listens on a TCP socket and another that dials it. The test case exercises the as well as the and IP allocation functionality.