Testground
GitHubGo SDKInfra
v0.5.3
v0.5.3
  • README
  • Table of contents
    • What is Testground?
    • Concepts and architecture
      • Test plans and test cases
      • Daemon and client
      • Synchronization service
      • Networking
      • Sidecar
      • Builders
      • Runners
      • Runtime environment (runenv)
      • Client-Server communication
    • Getting started
    • Writing test plans
      • Quick start
      • Understanding the test plan manifest
      • Parameters and test cases
      • Keeping instances in sync
      • Communication between instances
      • Observability, assets and metrics
    • Managing test plans
    • Running test plans
    • Traffic shaping
    • Analyzing test run results
      • Capturing profiles
    • Debugging test plans
    • Docker Settings
    • Featured projects
  • Runner library
    • local:exec
    • local:docker
      • System overview
      • Runner flags
      • Troubleshooting
    • cluster:k8s
      • System overview
      • How to create a Kubernetes cluster for Testground
      • Monitoring and Observability
      • Understanding Testground performance on Kubernetes
      • Troubleshooting
  • Builder Library
    • docker:go
    • exec:go
    • docker:generic
Powered by GitBook
On this page
  • Setting up thetopic
  • Publishing to a topic
  • Reading from a topic
  • Who subscribes and who publishes?
  • Full Example
  1. Table of contents
  2. Writing test plans

Communication between instances

For some test plans, it is useful to pass information from one instance to another. In addition to direct network connectivity, test plans can pass information between instances using the Testground sync service.

In this tutorial, we will explore typed message passing through the Testground sync service.

Lets create a plan in which one of the plans produces a struct which is re-constructed on the distant end. First, I'll show short snippets with the relevant information, and the whole test plan will be shown at the end.

Setting up thetopic

Transferrable is the value type we will be transferring.

type Transferrable struct {
  Name          string
  FavoriteSport int
  CareWhoKnows  bool
}

The value will be transferred over a topic. Think of the topic as a named and typed channel for transferring values between plan instances. This topic is named transfer-key and the value type I expect to get out of it is pointer to Transferrable.

st := sync.NewTopic("transfer-key", &Transferrable{})

Publishing to a topic

To write to a topic, create a bounded client and use it to publish to the topic we have just defined.

  ctx := context.Background()

  client := sync.MustBoundClient(ctx, runenv)
  defer client.Close()

  client.Publish(ctx, st, &Transferrable{"Guy#1", 1, false})

Reading from a topic

Subscribe to the topic we created earlier and set up a channel to receive the values.

  tch := make(chan *Transferrable)

  _, err = client.Subscribe(ctx, st, tch)
  if err != nil {
    panic(err)
  }

Who subscribes and who publishes?

This question is left up to the plan writer, and certainly different situations will call for different implementations. In this example, all the plans will publish and all will subscribe, but there are scenarios where this is inappropriate.

Full Example

package main

import (
	"context"
	"fmt"
	"math/rand"
	"time"

	"github.com/testground/sdk-go/run"
	"github.com/testground/sdk-go/runtime"
	"github.com/testground/sdk-go/sync"
)

type Sport int

const (
	football Sport = iota
	tennis
	hockey
	golf
)

func (s Sport) String() string {
	return [...]string{"football", "tennis", "hockey", "golf"}[s]
}

type Transferrable struct {
	Name          string
	FavoriteSport Sport
	CareWhoKnows  bool
}

func (t *Transferrable) String() string {
	msg := fmt.Sprintf("%s: I like %s", t.Name, t.FavoriteSport)
	if t.CareWhoKnows {
		return msg + " and I really care!"
	}
	return msg + " and I don't care who knows!"
}

func main() {
	run.Invoke(test)
}

func test(runenv *runtime.RunEnv) error {
	rand.Seed(time.Now().UnixNano())

	ctx := context.Background()
	client := sync.MustBoundClient(ctx, runenv)
	defer client.Close()

	st := sync.NewTopic("transfer-key", &Transferrable{})

	// Configure the test
	myName := fmt.Sprintf("Guy#%d", rand.Int()%100)
	mySport := Sport(rand.Int() % 4)
	howMany := runenv.TestInstanceCount

	// Publish my entry
	client.Publish(ctx, st, &Transferrable{myName, mySport, false})

	// Wait until all instances have published entries
	readyState := sync.State("ready")
	client.MustSignalEntry(ctx, readyState)
	<-client.MustBarrier(ctx, readyState, howMany).C

	// Subscribe to the `transfer-key` topic
	tch := make(chan *Transferrable)
	client.Subscribe(ctx, st, tch)

	for i := 0; i < howMany; i++ {
		t := <-tch
		runenv.RecordMessage("%s", t)
	}

	return nil
}

Run with multiple instances:

$ testground run single -p quickstart -t quickstart -b exec:go -r local:exec -i 4

?> Notice that instances is set to 4. Four instances will run at the same time.

PreviousKeeping instances in syncNextObservability, assets and metrics

Last updated 2 years ago