Testground
GitHubGo SDKInfra
master
master
  • README
  • Table of contents
    • What is Testground?
      • Community
    • 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
  • libp2p
  • Testground learning example
  1. Table of contents

Featured projects

PreviousDocker SettingsNextRunner library

Last updated 2 years ago

libp2p

libp2p is an open source networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. You can find the libp2p Testground plans in the .

Testground learning example

This project is intended as a practical example of a "real" project, with its own internal business logic, dependencies, etc. The logic and behaviors are intended to be as straightforward as possible, acting as a reference / guide on how to implement these behaviors and test them using Testground.

You can find the project in the following Github repositories:

Featured test cases

  • Running a build with the docker:generic builder, a custom Dockerfile and manifest.toml

  • Running an additional docker container as a dependency for tests (see the Makefile for an example)

  • Test cases which are intentionally written to fail, due to a context timeout, or a network routing policy that causes a node to be unreachable

Testground Plans Repository
Learning project
Testground plans