Robust framework for running complex workload scenarios in isolation, using Go; for integration, e2e tests, benchmarks and more! 💪

e2e

golang docs

Go Module providing robust framework for running complex workload scenarios in isolation, using Go and Docker. For integration, e2e tests, benchmarks and more! 💪

What are the goals?

  • Ability to schedule isolated processes programmatically from single process on single machine.
  • Focus on cluster workloads, cloud native services and microservices.
  • Developer scenarios in mind e.g preserving scenario readability, Go unit test integration.
  • Metric monitoring as the first citizen. Assert on Prometheus metric values during test scenarios or check overall performance characteristics.

Usage Models

There are three main use cases envisioned for this Go module:

  • Unit test use (see example). Use e2e in unit tests to quickly run complex test scenarios involving many container services. This was the main reason we created this module. You can check usage of it in Cortex and Thanos projects.
  • Standalone use (see example). Use e2e to run setups in interactive mode where you spin up workloads as you want programmatically and poke with it on your own using your browser or other tools. No longer need to deploy full Kubernetes or external machines.
  • Benchmark use (see example). Use e2e in local Go benchmarks when your code depends on external services with ease.

Getting Started

Let's go through an example leveraging go test flow:

  1. Implement the workload by embeddinge2e.Runnable or *e2e.InstrumentedRunnable. Or you can use existing ones in e2edb package. For example implementing Thanos Querier with our desired configuration could look like this:

    func newThanosSidecar(env e2e.Environment, name string, prom e2e.Linkable) *e2e.InstrumentedRunnable {
    	ports := map[string]int{
    		"http": 9090,
    		"grpc": 9091,
    	}
    	return e2e.NewInstrumentedRunnable(env, name, ports, "http", e2e.StartOptions{
    		Image: "quay.io/thanos/thanos:v0.21.1",
    		Command: e2e.NewCommand("sidecar", e2e.BuildArgs(map[string]string{
    			"--debug.name":     name,
    			"--grpc-address":   fmt.Sprintf(":%d", ports["grpc"]),
    			"--http-address":   fmt.Sprintf(":%d", ports["http"]),
    			"--prometheus.url": "http://" + prom.InternalEndpoint(e2edb.AccessPortName),
    			"--log.level":      "info",
    		})...),
    		Readiness: e2e.NewHTTPReadinessProbe("http", "/-/ready", 200, 200),
    		User:      strconv.Itoa(os.Getuid()),
    	})
    }
  2. Implement test. Start by creating environment. Currently e2e supports Docker environment only. Use unique name for all your tests. It's recommended to keep it stable so resources are consistently cleaned.

    	// Start isolated environment with given ref.
    	e, err := e2e.NewDockerEnvironment("e2e_example")
    	testutil.Ok(t, err)
    	// Make sure resources (e.g docker containers, network, dir) are cleaned.
    	t.Cleanup(e.Close)
  3. Program your scenario as you want. You can start, wait for their readiness, stop, check their metrics and use their network endpoints from both unit test (Endpoint) as well as within each workload (InternalEndpoint). You can also access workload directory. There is a shared directory across all workloads. Check Dir and InternalDir runnable methods.

    	// Create structs for Prometheus containers scraping itself.
    	p1, err := e2edb.NewPrometheus(e, "prometheus-1")
    	testutil.Ok(t, err)
    	s1 := newThanosSidecar(e, "sidecar-1", p1)
    
    	p2, err := e2edb.NewPrometheus(e, "prometheus-2")
    	testutil.Ok(t, err)
    	s2 := newThanosSidecar(e, "sidecar-2", p2)
    
    	// Create Thanos Query container. We can point the peer network addresses of both Prometheus instance
    	// using InternalEndpoint methods, even before they started.
    	t1 := newThanosQuerier(e, "query-1", s1.InternalEndpoint("grpc"), s2.InternalEndpoint("grpc"))
    
    	// Start them.
    	testutil.Ok(t, e2e.StartAndWaitReady(p1, s1, p2, s2, t1))
    
    	// To ensure query should have access we can check its Prometheus metric using WaitSumMetrics method. Since the metric we are looking for
    	// only appears after init, we add option to wait for it.
    	testutil.Ok(t, t1.WaitSumMetricsWithOptions(e2e.Equals(2), []string{"thanos_store_nodes_grpc_connections"}, e2e.WaitMissingMetrics()))
    
    	// To ensure Prometheus scraped already something ensure number of scrapes.
    	testutil.Ok(t, p1.WaitSumMetrics(e2e.Greater(50), "prometheus_tsdb_head_samples_appended_total"))
    	testutil.Ok(t, p2.WaitSumMetrics(e2e.Greater(50), "prometheus_tsdb_head_samples_appended_total"))
    
    	// We can now query Thanos Querier directly from here, using it's host address thanks to Endpoint method.
    	a, err := api.NewClient(api.Config{Address: "http://" + t1.Endpoint("http")})
    	testutil.Ok(t, err)
    
    	{
         now := model.Now()
         v, w, err := v1.NewAPI(a).Query(context.Background(), "up{}", now.Time())
         testutil.Ok(t, err)
         testutil.Equals(t, 0, len(w))
         testutil.Equals(
             t,
             fmt.Sprintf(`up{instance="%v", job="myself", prometheus="prometheus-1"} => 1 @[%v]
    up{instance="%v", job="myself", prometheus="prometheus-2"} => 1 @[%v]`, p1.InternalEndpoint(e2edb.AccessPortName), now, p2.InternalEndpoint(e2edb.AccessPortName), now),
             v.String(),
         )
    	}
    
    	// Stop first Prometheus and sidecar.
    	testutil.Ok(t, s1.Stop())
    	testutil.Ok(t, p1.Stop())
    
    	// Wait a bit until Thanos drops connection to stopped Prometheus.
    	testutil.Ok(t, t1.WaitSumMetricsWithOptions(e2e.Equals(1), []string{"thanos_store_nodes_grpc_connections"}, e2e.WaitMissingMetrics()))
    
    	{
         now := model.Now()
         v, w, err := v1.NewAPI(a).Query(context.Background(), "up{}", now.Time())
         testutil.Ok(t, err)
         testutil.Equals(t, 0, len(w))
         testutil.Equals(
             t,
             fmt.Sprintf(`up{instance="%v", job="myself", prometheus="prometheus-2"} => 1 @[%v]`, p2.InternalEndpoint(e2edb.AccessPortName), now),
             v.String(),
         )
    	}
    }

Credits

Comments
  • Remove `RunOnce`

    Remove `RunOnce`

    Hm, so I create RunOnce API but actually I forgot I managed to solve my use case without this in https://github.com/thanos-io/thanos/blob/main/test/e2e/compatibility_test.go#L62

    It's as easy as creating noop container and doing execs...

    // Start noop promql-compliance-tester. See https://github.com/prometheus/compliance/tree/main/promql on how to build local docker image.
    	compliance := e.Runnable("promql-compliance-tester").Init(e2e.StartOptions{
    		Image:   "promql-compliance-tester:latest",
    		Command: e2e.NewCommandWithoutEntrypoint("tail", "-f", "/dev/null"),
    	})
    	testutil.Ok(t, e2e.StartAndWaitReady(compliance))
    // ...
    		stdout, stderr, err := compliance.Exec(e2e.NewCommand("/promql-compliance-tester", "-config-file", filepath.Join(compliance.InternalDir(), "receive.yaml")))
    		t.Log(stdout, stderr)
    		testutil.Ok(t, err)
    	})
    

    I think we should kill RunOnce API to simplify all - and put the above into examples? 🤔

    cc @saswatamcode @PhilipGough @matej-g ?

  • Minio is not ready even after `StartAndWaitReady` completes

    Minio is not ready even after `StartAndWaitReady` completes

    Issue description

    Trying to start Minio on the latest version of main, the server is not ready to handle requests, despite StartAndWaitReady being ran successfully already. Any immediate requests afterwards result in error response Server not initialized, please try again.

    I suspect this could be an issue with the readiness probe upstream, since when setting up the same scenario with code version from before Minio image update in https://github.com/efficientgo/e2e/pull/4, everything is working correctly. However, I haven't confirmed the exact cause yet.

    Minimal setup to reproduce

    Run this test:

    import (
    	"context"
    	"io/ioutil"
    	"testing"
    
    	"github.com/efficientgo/e2e"
            e2edb "github.com/efficientgo/e2e/db"
    	"github.com/efficientgo/tools/core/pkg/testutil"
    	"github.com/minio/minio-go/v7"
    	"github.com/minio/minio-go/v7/pkg/credentials"
    )
    
    func TestMinio(t *testing.T) {
    	e, err := e2e.NewDockerEnvironment("minio_test", e2e.WithVerbose())
    	testutil.Ok(t, err)
    	t.Cleanup(e.Close)
    
    	const bucket = "minoiotest"
    	m := e2edb.NewMinio(e, "minio", bucket)
    	testutil.Ok(t, e2e.StartAndWaitReady(m))
    
    	mc, err := minio.New(m.Endpoint("http"), &minio.Options{
    		Creds: credentials.NewStaticV4(e2edb.MinioAccessKey, e2edb.MinioSecretKey, ""),
    	})
    	testutil.Ok(t, err)
    	testutil.Ok(t, ioutil.WriteFile("test.txt", []byte("just a test"), 0755))
    
    	_, err = mc.FPutObject(context.Background(), bucket, "obj", "./test.txt", minio.PutObjectOptions{})
    	testutil.Ok(t, err)
    }
    
  • Possibility of infinite loop when waiting for missing metrics to appear

    Possibility of infinite loop when waiting for missing metrics to appear

    When using InstrumentedRunnable.WaitSumMetricsWithOptions(...) together with e2e.WaitMissingMetrics() it's possible that tests get stuck forever because of this loop.

    It would be great to have a safety mechanism to timeout the wait. It helps avoid long running CI jobs, which can be $$$ friendly.

  • monitoring: allow compilation for non-Linux

    monitoring: allow compilation for non-Linux

    This commit extracts the Linux-specific code into files that are guarded by Golang build flags, allowing binaries that import the e2e/monitoring package to compile on non-Linux operating systems. I tested this with the following main.go and was able to compile a binary for both Darwin and Windows:

    package main
    
    import (
    	"fmt"
    
    	m "github.com/efficientgo/e2e/monitoring"
    )
    
    func main() {
    	s := m.Service{}
    	fmt.Println(s)
    }
    

    Fixes: https://github.com/efficientgo/e2e/issues/15

    Signed-off-by: Lucas Servén Marín [email protected]

  • `monitoring` package is not usable on MacOS

    `monitoring` package is not usable on MacOS

    See the report in https://github.com/thanos-io/thanos/issues/4642.

    The monitoring package uses github.com/containerd/cgroups, which seem to include code usable only on Linux platforms. We should find a way to make code from monitoring run on MacOS as well.

  • Object does not exist error without pre pulling.

    Object does not exist error without pre pulling.

    Sometimes I was getting weird errors of objects does not exist for new docker images. What always worked was:

    • I had to run e2e with WithVerbose option
    • copy docker run ... command for problematic image.
    • Run it manually locally

    After that all runs 100% works.

    Leaving here as a known issue to debug (: I suspect some permissions on my machines? 🤔 Let's see if other can repro!

  • Use minio console access as readiness check

    Use minio console access as readiness check

    Signed-off-by: Douglas Camata [email protected]

    This should fix #11. As my comment there mentions, I applied the same solution used at https://github.com/thanos-io/thanos/pull/5615: using the MinIO console as readiness check. It has been working well there so far.

    As an addition I added a small and basic test for the NewMinio function.

  • monitoring: Add option to disable cadvisor

    monitoring: Add option to disable cadvisor

    Cadvisor is important to get container metrics. However, it requires various directories, which might be different on different OS-es causing it to fail. For example when using WSL (https://github.com/google/cadvisor/issues/2648#issuecomment-1049215354).

    Without cadvisor we still can have a lot of metrics from runtimes running in containers (e.g Go app), so we can add option to disable cadvisor so users can be unblocked if they can't make cadvisor running.

  • Add back GetMonitoringRunnable method

    Add back GetMonitoringRunnable method

    Signed-off-by: Ben Ye [email protected]

    Add back GetMonitoringRunnable method for the meta monitoring usecase https://github.com/thanos-io/thanos/blob/main/test/e2e/receive_test.go#L668.

  • Refactored instrumented; Added profiling; better error handling

    Refactored instrumented; Added profiling; better error handling

    NOTE: This breaks API, but it should be now more consistent, easier to use and easier to extend.

    I tried different approaches, but I found that splitting extensions to different packages (e.g profiling and monitoring) and simplifying will work the best. Let me know what you think!

    Essentially this replaces definition like this:

    return e2e.NewInstrumentedRunnable(env, name).WithPorts(map[string]int{AccessPortName: 2379, "metrics": 9000}, "metrics").Init(
    		e2e.StartOptions{
    			Image:     o.image,
    			Command:   e2e.NewCommand("/usr/local/bin/etcd", "--listen-client-urls=http://0.0.0.0:2379", "--advertise-client-urls=http://0.0.0.0:2379", "--listen-metrics-urls=http://0.0.0.0:9000", "--log-level=error"),
    			Image: o.image,
    			Command: e2e.NewCommand(
    				"/usr/local/bin/etcd",
    				"--listen-client-urls=http://0.0.0.0:2379",
    				"--advertise-client-urls=http://0.0.0.0:2379",
    				"--listen-metrics-urls=http://0.0.0.0:9000",
    				"--log-level=error",
    			),
    			Readiness: e2e.NewHTTPReadinessProbe("metrics", "/health", 200, 204),
    		},
    )
    

    with

    return e2emon.AsInstrumented(env.Runnable(name).WithPorts(map[string]int{AccessPortName: 2379, "metrics": 9000}).Init(
    		e2e.StartOptions{
    			Image:     o.image,
    			Command:   e2e.NewCommand("/usr/local/bin/etcd", "--listen-client-urls=http://0.0.0.0:2379", "--advertise-client-urls=http://0.0.0.0:2379", "--listen-metrics-urls=http://0.0.0.0:9000", "--log-level=error"),
    			Image: o.image,
    			Command: e2e.NewCommand(
    				"/usr/local/bin/etcd",
    				"--listen-client-urls=http://0.0.0.0:2379",
    				"--advertise-client-urls=http://0.0.0.0:2379",
    				"--listen-metrics-urls=http://0.0.0.0:9000",
    				"--log-level=error",
    			),
    			Readiness: e2e.NewHTTPReadinessProbe("metrics", "/health", 200, 204),
    		},
    	)
    ), "metrics")
    

    Not a big deal from usage, but much more cleaner when we start adding other extension to runnables like profiling.

  • Fix tests on arm64 & GH Actions

    Fix tests on arm64 & GH Actions

    Also on amd64, as a bonus. make test wasn't passing on a fresh instance of Codespaces before the changes.

    I took the freedom to fix the Github Actions configuration that was programmed to run builds on pushes to master, but this repository uses main as default branch.

  • Add docker-slim support

    Add docker-slim support

    Add type dockerSlimRunnable to be able to run conatiners and build slim images with docker-slim. Some of the differences compared to dockerRunnable:

    • The slim image name will the original image with a suffix "-slim".
    • The container name always dynamically generated and can not be changed.
    • There is option to specify extra arguments to the docker-slim build command.
    • For stopping the conatiner the Stop and Kill functions send USR1 signal to docker-slim.

    I tested the code with docker-slim and the it runs well and build the slim image after tests are finished but the container logs only available after the docker-slim stopped it.

  • Add GC to unused docker networks.

    Add GC to unused docker networks.

    We could make test cleanup more reliable following a similar pattern as in https://golang.testcontainers.org/features/garbage_collector/

    Perhaps one container that deletes the whole network? (no need for sidecars).

    What would be enough is to on the next run kill all unused networks and find a way how to check if network used used (perhaps some expiry files)

  • idea: Declarative K8s API as the API for docker env.

    idea: Declarative K8s API as the API for docker env.

    Just an idea: But it would be amazing to contain some service like e2e.Runnable or instrumented e2e.Runnable in a declarative, mutable state. Ideally, something that speaks a common language like K8s APIs. Then have docker engine supporting an important subset of K8s API for local use. There would be a few benefits to this:

    • We would be able to compose adjustments of e.g flags for different tests together better like Jsonnet allows (also adds huge cognitive load potentially!). The current approach has similar issues to https://github.com/bwplotka/mimic initial deployment at Improbable - the input for adjusting services is getting out of control (check ruler or querier helpers for e.g https://github.com/thanos-io/thanos/pull/5348)
    • We could REUSE some Infrastructure as Go code (e.g. https://github.com/bwplotka/mimic) for both productions, staging, testing etc K8s clusters AS WELL AS local simplified e2e docker environments!
  • Permissions of DockerEnvironment.SharedDir()

    Permissions of DockerEnvironment.SharedDir()

    I had several hours of confusion and difficulty because on my test machine the Docker instances received a /shared directory (holding /shared/config etc) with permissions rwxr-xr-x but on a CircleCI machine running a PR the Docker instances saw permissions rwx------ for /shared.

    (This affects test containers that don't run as root.)

    It is unclear to me if the problem is that only I am using Docker on a Mac, I am using Go 1.17, or I have a different umask than the CircleCI machine. I tried setting my umask to 000 but was unable to get my builds to fail the same way as the CircleCI builds.

  • BuildArgs should support repeating arguments

    BuildArgs should support repeating arguments

    It is not uncommon that some programs support repeating arguments to provide multiple values, i.e. in following format: example -p "first argument" -p "second one" -p "third one"

    It is currently not possible to use BuildArgs to build arguments in such way, since it depends on using map[string]string, thus not allowing for repeated values.

Package has tool to generate workload for vegeta based kube-api stress tests.

Package has tool to generate workload for vegeta based kube-api stress tests.

Nov 22, 2021
HTTP mocking to test API services for chaos scenarios
HTTP mocking to test API services for chaos scenarios

GAOS HTTP mocking to test API services for chaos scenarios Gaos, can create and provide custom mock restful services via using your fully-customizable

Nov 5, 2022
The test suite to demonstrate the chaos experiment behavior in different scenarios

Litmus-E2E The goal of litmus e2e is to provide the test suite to demonstrate the chaos experiment behavior in different scenarios. As the name sugges

Jul 7, 2022
A workload generator for MySQL compatible databases

Diligent is a tool we created at Flipkart for generating workloads for our SQL databases that enables us to answer specific questions about the performance of a database.

Nov 9, 2022
Testing framework for Go. Allows writing self-documenting tests/specifications, and executes them concurrently and safely isolated. [UNMAINTAINED]

GoSpec GoSpec is a BDD-style testing framework for the Go programming language. It allows writing self-documenting tests/specs, and executes them in p

Nov 28, 2022
http integration test framework

go-hit hit is an http integration test framework written in golang. It is designed to be flexible as possible, but to keep a simple to use interface f

Dec 29, 2022
Partial fork of testify framework with allure integration
Partial fork of testify framework with allure integration

allure-testify Оглавление Demo Getting started Examples Global environments keys How to use suite Allure info Test info Label Link Allure Actions Step

Dec 1, 2021
Simple HTTP integration test framework for Golang

go-itest Hassle-free REST API testing for Go. Installation go get github.com/jefflinse/go-itest Usage Create tests for your API endpoints and run the

Jan 8, 2022
Snapshot - snapshot provides a set of utility functions for creating and loading snapshot files for using snapshot tests.

Snapshot - snapshot provides a set of utility functions for creating and loading snapshot files for using snapshot tests.

Jan 27, 2022
Full-featured test framework for Go! Assertions, mocking, input testing, output capturing, and much more! 🍕
Full-featured test framework for Go! Assertions, mocking, input testing, output capturing, and much more! 🍕

testza ?? Testza is like pizza for Go - you could life without it, but why should you? Get The Module | Documentation | Contributing | Code of Conduct

Dec 10, 2022
Testy is a Go test running framework designed for Gametime's API testing needs.

template_library import "github.com/gametimesf/template_library" Overview Index Overview Package template_library is a template repository for buildin

Jun 21, 2022
Record and replay your HTTP interactions for fast, deterministic and accurate tests

go-vcr go-vcr simplifies testing by recording your HTTP interactions and replaying them in future runs in order to provide fast, deterministic and acc

Dec 25, 2022
A mock of Go's net package for unit/integration testing

netmock: Simulate Go network connections netmock is a Go package for simulating net connections, including delays and disconnects. This is work in pro

Oct 27, 2021
Extremely flexible golang deep comparison, extends the go testing package and tests HTTP APIs
Extremely flexible golang deep comparison, extends the go testing package and tests HTTP APIs

go-testdeep Extremely flexible golang deep comparison, extends the go testing package. Latest news Synopsis Description Installation Functions Availab

Dec 22, 2022
A next-generation testing tool. Orion provides a powerful DSL to write and automate your acceptance tests

Orion is born to change the way we implement our acceptance tests. It takes advantage of HCL from Hashicorp t o provide a simple DSL to write the acceptance tests.

Aug 31, 2022
A simple and expressive HTTP server mocking library for end-to-end tests in Go.

mockhttp A simple and expressive HTTP server mocking library for end-to-end tests in Go. Installation go get -d github.com/americanas-go/mockhttp Exa

Dec 19, 2021
How we can run unit tests in parallel mode with failpoint injection taking effect and without injection race

This is a simple demo to show how we can run unit tests in parallel mode with failpoint injection taking effect and without injection race. The basic

Oct 31, 2021
Package for comparing Go values in tests

Package for equality of Go values This package is intended to be a more powerful and safer alternative to reflect.DeepEqual for comparing whether two

Dec 29, 2022
Go testing in the browser. Integrates with `go test`. Write behavioral tests in Go.
Go testing in the browser. Integrates with `go test`. Write behavioral tests in Go.

GoConvey is awesome Go testing Welcome to GoConvey, a yummy Go testing tool for gophers. Works with go test. Use it in the terminal or browser accordi

Dec 30, 2022