istio源码20221231

# Istio Integration Tests This folder contains Istio integration tests that use the test framework checked in at [istio.io/istio/pkg/test/framework](https://github.com/istio/istio/tree/master/pkg/test/framework). ## Table of Contents 1. [Overview](#overview) 1. [Writing Tests](#writing-tests) 1. [Adding a Test Suite](#adding-a-test-suite) 1. [Sub-Tests](#sub-tests) 1. [Parallel Tests](#parallel-tests) 1. [Using Components](#using-components) 1. [Writing Components](#writing-components) 1. [Running Tests](#running-tests) 1. [Test Parallelism and Kubernetes](#test-parellelism-and-kubernetes) 1. [Test Selection](#test-selection) 1. [Running Tests on CI](#running-tests-on-ci) 1. [Step 1: Add a Test Script](#step-1-add-a-test-script) 1. [Step 2: Add a Prow Job](#step-2-add-a-prow-job) 1. [Step 3: Update TestGrid](#step-3-update-testgrid) 1. [Environments](#environments) 1. [Diagnosing Failures](#diagnosing-failures) 1. [Working Directory](#working-directory) 1. [Enabling CI Mode](#enabling-ci-mode) 1. [Preserving State (No Cleanup)](#preserving-state-no-cleanup) 1. [Additional Logging](#additional-logging) 1. [Running Tests Under Debugger](#running-tests-under-debugger-goland) 1. [Reference](#reference) 1. [Helm Values Overrides](#helm-values-overrides) 1. [Commandline Flags](#command-line-flags) 1. [Notes](#notes) 1. [Running on a Mac](#running-on-a-mac) ## Overview The goal of the framework is to make it as easy as possible to author and run tests. In its simplest case, just typing ```go test ./...``` should be sufficient to run tests. This guide walks through the basics of writing tests with the Istio test framework. For best practices, see [Writing Good Integration Tests](https://github.com/istio/istio/wiki/Writing-Good-Integration-Tests). ## Writing Tests The test framework is designed to work with standard go tooling and allows developers to write environment-agnostics tests in a high-level fashion. ### Adding a Test Suite All tests that use the framework, must run as part of a *suite*. Only a single suite can be defined per package, since it is bootstrapped by a Go `TestMain`, which has the same restriction. To begin, create a new folder for your suite under [tests/integration](https://github.com/istio/istio/tree/master/tests/integration). ```console $ cd ${ISTIO}/tests/integration $ mkdir mysuite ``` Within that package, create a `TestMain` to bootstrap the test suite: ```go func TestMain(m *testing.M) { framework. NewSuite("mysuite", m). Run() } ``` Next, define your tests in the same package: ```go func TestMyLogic(t *testing.T) { framework. NewTest(t). Run(func(ctx framework.TestContext) { // Create a component p := pilot.NewOrFail(ctx, ctx, cfg) // Use the component. // Apply Kubernetes Config ctx.ApplyConfigOrFail(ctx, nil, mycfg) // Do more stuff here. } } ``` The `framework.TestContext` is a wrapper around the underlying `testing.T` and implements the same interface. Test code should generally not interact with the `testing.T` directly. In the `TestMain`, you can also restrict the test to particular environment, apply labels, or do test-wide setup, such as deploying Istio. ```go func TestMain(m *testing.M) { framework. NewSuite("mysuite", m). // Deploy Istio on the cluster Setup(istio.Setup(nil, nil)). // Run your own custom setup Setup(mySetup). Run() } func mySetup(ctx resource.Context) error { // Your own setup code return nil } ``` ### Sub-Tests Go allows you to run sub-tests with `t.Run()`. Similarly, this framework supports nesting tests with `ctx.NewSubTest()`: ```go func TestMyLogic(t *testing.T) { framework. NewTest(t). Run(func(ctx framework.TestContext) { // Create a component g := galley.NewOrFail(ctx, ctx, cfg) configs := []struct{ name: string yaml: string } { // Some array of YAML } for _, cfg := range configs { ctx.NewSubTest(cfg.name). Run(func(ctx framework.TestContext) { ctx.ApplyConfigOrFail(ctx, nil, mycfg) // Do more stuff here. }) } }) } ``` Under the hood, calling `subtest.Run()` delegates to `t.Run()` in order to create a child `testing.T`. ### Parallel Tests Many tests can take a while to start up for a variety of reasons, such as waiting for pods to start or waiting for a particular piece of configuration to propagate throughout the system. Where possible, it may be desirable to run these sorts of tests in parallel: ```go func TestMyLogic(t *testing.T) { framework. NewTest(t). RunParallel(func(ctx framework.TestContext) { // ... } } ``` Under the hood, this relies on Go's `t.Parallel()` and will, therefore, have the same behavior. A parallel test will run in parallel with siblings that share the same parent test. The parent test function will exit before the parallel children are executed. It should be noted that if the parent test is prevented from exiting (e.g. parent test is waiting for something to occur within the child test), the test will deadlock. Consider the following example: ```go func TestMyLogic(t *testing.T) { framework.NewTest(t). Run(func(ctx framework.TestContext) { ctx.NewSubTest("T1"). Run(func(ctx framework.TestContext) { ctx.NewSubTest("T1a"). RunParallel(func(ctx framework.TestContext) { // Run in parallel with T1b }) ctx.NewSubTest("T1b"). RunParallel(func(ctx framework.TestContext) { // Run in parallel with T1a }) // Exits before T1a and T1b are run. }) ctx.NewSubTest("T2"). Run(func(ctx framework.TestContext) { ctx.NewSubTest("T2a"). RunParallel(func(ctx framework.TestContext) { // Run in parallel with T2b }) ctx.NewSubTest("T2b"). RunParallel(func(ctx framework.TestContext) { // Run in parallel with T2a }) // Exits before T2a and T2b are run. }) }) } ``` In the example above, non-parallel parents T1 and T2 contain parallel children T1a, T1b, T2a, T2b. Since both T1 and T2 are non-parallel, they are run synchronously: T1 followed by T2. After T1 exits, T1a and T1b are run asynchronously with each other. After T1a and T1b complete, T2 is then run in the same way: T2 exits, then T2a and T2b are run asynchronously to completion. ### Using Components The framework itself is just a platform for running tests and tracking resources. Without these `resources`, there isn't much added value. Enter: components. Components are utilities that provide abstractions for Istio resources. They are maintained in the [components package](https://github.com/istio/istio/tree/master/pkg/test/framework/components), which defines various Istio components such as galley, pilot, and namespaces. Each component defines their own API which simplifies their use from test code, abstracting away the environment-specific details. This means that the test code can (and should, whe