moduletest

package
v1.8.0-rc1 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jul 23, 2024 License: MPL-2.0 Imports: 10 Imported by: 0

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

This section is empty.

Types

type File

type File struct {
	Config *configs.TestFile

	Name   string
	Status Status

	Runs []*Run

	Diagnostics tfdiags.Diagnostics
}

type Run

type Run struct {
	Config *configs.TestRun

	Verbose *Verbose

	Name   string
	Index  int
	Status Status

	Diagnostics tfdiags.Diagnostics
}

func (*Run) GetReferences

func (run *Run) GetReferences() ([]*addrs.Reference, tfdiags.Diagnostics)

func (*Run) GetReplaces

func (run *Run) GetReplaces() ([]addrs.AbsResourceInstance, tfdiags.Diagnostics)

func (*Run) GetTargets

func (run *Run) GetTargets() ([]addrs.Targetable, tfdiags.Diagnostics)

func (*Run) ValidateExpectedFailures

func (run *Run) ValidateExpectedFailures(originals tfdiags.Diagnostics) tfdiags.Diagnostics

ValidateExpectedFailures steps through the provided diagnostics (which should be the result of a plan or an apply operation), and does 3 things:

  1. Removes diagnostics that match the expected failures from the config.
  2. Upgrades warnings from check blocks into errors where appropriate so the test will fail later.
  3. Adds diagnostics for any expected failures that were not satisfied.

Point 2 is a bit complicated so worth expanding on. In normal OpenTofu execution, any error that originates within a check block (either from an assertion or a scoped data source) is wrapped up as a Warning to be identified to the user but not to fail the actual OpenTofu operation. During test execution, we want to upgrade (or rollback) these warnings into errors again so the test will fail. We do that as part of this function as we are already processing the diagnostics from check blocks in here anyway.

The way the function works out which diagnostics are relevant to expected failures is by using the tfdiags Extra functionality to detect which diagnostics were generated by custom conditions. OpenTofu adds the addrs.CheckRule that generated each diagnostic to the diagnostic itself so we can tell which diagnostics can be expected.

type Status

type Status int

Status represents the status of a test case, and is defined as an iota within this file.

The order of the definitions matter as different statuses do naturally take precedence over others. A test suite that has a mix of pass and fail statuses has failed overall and therefore the fail status is of higher precedence than the pass status.

See the Status.Merge function for this requirement being used in action.

const (
	Pending Status = iota
	Skip
	Pass
	Fail
	Error
)

func (Status) Merge

func (status Status) Merge(next Status) Status

Merge compares two statuses and returns a status that best represents the two together.

This should be used to collate the overall status of a test file or test suite from the collection of test runs that have been executed.

Essentially, if a test suite has a bunch of failures and passes the overall status would be failure. If a test suite has all passes, then the test suite would be pass overall.

The implementation basically always returns the highest of the two, which means the order the statuses are defined within the iota matters.

func (Status) String

func (i Status) String() string

type Suite

type Suite struct {
	Status Status

	Files map[string]*File
}

type Verbose

type Verbose struct {
	Plan         *plans.Plan
	State        *states.State
	Config       *configs.Config
	Providers    map[addrs.Provider]providers.ProviderSchema
	Provisioners map[string]*configschema.Block
}

Verbose is a utility struct that holds all the information required for a run to render the results verbosely.

At the moment, this basically means printing out the plan. To do that we need all the information within this struct.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL