Команда: test
Команда tofu test позволяет проверить конфигурацию OpenTofu, создав реальную инфраструктуру и убедившись, что необходимые условия (утверждения) выполнены. После завершения теста OpenTofu уничтожает созданные ресурсы.
Использование
Использование: tofu test [options].
Эта команда выполнит все файлы *.tftest.hcl, *.tftest.json, *.tofutest.hcl и *.tofutest.json в текущем каталоге или в каталоге с именем tests. Это поведение можно настроить с помощью приведённых ниже параметров.
Рассмотрим следующий простой пример, в котором из main.tf создаётся файл test.txt, а затем проверяется, что основной код успешно выполнил свою задачу, используя main.tftest.hcl.
- main.tf
- main.tftest.hcl
resource "local_file" "test" {
filename = "${path.module}/test.txt"
content = "Hello world!"
}run "test" {
assert {
condition = file(local_file.test.filename) == "Hello world!"
error_message = "Incorrect content in ${local_file.test.filename}."
}
}Выполните tofu init, а затем tofu test, чтобы запустить тест: он применит файл main.tf и проверит его по утверждению в main.tftest.hcl. Это лишь простой пример. Ниже приведены более подробные примеры.
Приоритет расширений
Если в каталоге присутствуют файлы .tftest.hcl и .tofutest.hcl с одинаковым базовым именем, OpenTofu отдаст приоритет файлу .tofutest.hcl и проигнорирует файл .tftest.hcl. Например:
- Если в одном каталоге существуют файлы
main.tftest.hclиmain.tofutest.hcl, OpenTofu загрузит толькоmain.tofutest.hclи проигнорируетmain.tftest.hcl.
Это гарантирует, что файлы .tofu всегда имеют приоритет над файлами .tf, если доступны оба варианта. Это может быть полезно авторам модулей, которые хотят обеспечить совместимость своих модулей с OpenTofu и Terraform и создавать отдельные тесты для каждого из них.
- если в одном каталоге существуют файлы
main.tftest.jsonиmain.tofutest.json, OpenTofu загрузит толькоmain.tofutest.jsonи проигнорируетmain.tftest.json.
Параметры
-
-test-directory=pathЗадаёт каталог тестов (по умолчанию: "tests"). OpenTofu будет искать тестовые файлы в указанном каталоге, а также в текущем каталоге при запускеtofu test. Путь должен быть задан относительно текущего рабочего каталога. -
-filter=testfileЗадаёт отдельный тестовый файл для запуска. Используйте этот параметр несколько раз, чтобы указать несколько файлов. Путь должен быть задан относительно текущего рабочего каталога.
Если -filter используется вместе с -test-directory=path, перед каждым фильтром тестовых файлов в <test-directory> необходимо указывать <test-directory>, например:
tofu test -test-directory=extra-tests -filter=extra-tests/a.tftest.hcl
-
-var 'foo=bar'Задаёт входную переменную корневого модуля. Укажите этот параметр несколько раз, чтобы добавить несколько переменных. -
-var-file=filenameЗадаёт несколько переменных из указанного файла. Помимо этого файла OpenTofu автоматически загружаетterraform.tfvarsи*.auto.tfvars. Используйте этот параметр несколько раз, чтобы указать несколько файлов. -
-jsonИзменяет формат вывода на JSON. -
-json-into=out.json— формирует тот же вывод, что и -json, но перенаправляет его в файл. Это позволяет одновременно записывать журналы в удобном для чтения человеком и машиночитаемом форматах. -
-no-colorОтключает цветное оформление вывода команды. -
-verboseВыводит план или состояние для каждого блока запуска теста по мере его выполнения.
Использование переменных в источниках модулей, конфигурации серверной части или блоке шифрования требует присваивания значений переменным корневого модуля при запуске tofu test.
Структура каталогов
Команда tofu test поддерживает два варианта структуры каталогов: плоскую и вложенную.
- Плоская структура
- Вложенная структура
При такой структуре тестовые файлы *.tftest.hcl располагаются рядом с проверяемыми ими файлами *.tf. Нет требования, чтобы для каждого файла *.tf был отдельный тестовый файл, но рекомендуется придерживаться этой практики.
. ├── main.tf ├── main.tftest.hcl ├── foo.tf ├── foo.tftest.hcl ├── bar.tf └── bar.tftest.hcl
При такой структуре файлы *.tftest.hcl располагаются в отдельном каталоге tests. Как и при плоской структуре, нет требования, чтобы для каждого файла *.tf был отдельный тестовый файл, но рекомендуется придерживаться этой практики.
.
├── main.tf
├── foo.tf
├── bar.tf
└── tests
├── main.tftest.hcl
├── foo.tftest.hcl
└── bar.tftest.hclТестирование модулей
При тестировании модулей для каждого модуля можно использовать один из описанных выше вариантов структуры каталогов:
- Плоская структура
- Вложенная структура
При такой структуре запустите tofu test -test-directory=./path/to/module, чтобы протестировать нужный модуль.
.
├── module1
│ ├── main.tf
│ ├── main.tftest.hcl
│ ├── foo.tf
│ ├── foo.tftest.hcl
│ ├── bar.tf
│ └── bar.tftest.hcl
└── module2
└── ...При такой структуре перейдите в рабочем каталоге к пути вашего модуля и запустите tofu test, чтобы протестировать нужный модуль.
.
├── module1
│ ├── main.tf
│ ├── foo.tf
│ ├── bar.tf
│ └── tests
│ ├── main.tftest.hcl
│ ├── foo.tftest.hcl
│ └── bar.tftest.hcl
└── module2
└── ...Используйте параметр -filter=sometest.tftest.hcl, чтобы запустить ограниченный набор тестовых файлов. Чтобы запустить несколько тестовых файлов, укажите этот параметр несколько раз.
Структура файлов *.tftest.hcl / *.tofutest.hcl
Язык тестирования OpenTofu похож на основной язык OpenTofu и использует такую же структуру блоков.
Тестовый файл состоит из следующих элементов:
- Блоки
run: определяют тесты. - Блок
variables(необязательно): задаёт переменные для всех тестов в текущем файле. - Блоки
provider(необязательно): задают провайдеры, используемые в тестах. - Блоки
mock_provider(необязательно): задают провайдеры, для которых следует использовать имитации. - Блоки
override_resource(необязательно): задают ресурсы, которые следует переопределить. - Блоки
override_data(необязательно): задают источники данных, которые следует переопределить. - Блоки
override_module(необязательно): задают вызовы модулей, которые следует переопределить.
Блок run
Блок run содержит один тестовый сценарий, который выполняет tofu apply или tofu plan, а затем проверяет все блоки assert. После завершения теста OpenTofu использует tofu destroy для удаления временно созданных ресурсов.
Блок run состоит из следующих элементов:
| Имя | Тип | Описание |
|---|---|---|
assert |
блок | Определяет утверждения, проверяющие, правильно ли ваш код (например, main.tf) создал инфраструктуру. Если не указать блоки assert, OpenTofu просто применит конфигурацию без каких-либо утверждений. |
module |
блок | Переопределяет тестируемый модуль. Это можно использовать для загрузки вспомогательного модуля при выполнении более сложных тестов. |
expect_failures |
список | Список ресурсов, создание которых должно завершиться ошибкой при текущем запуске. |
variables |
блок | Задаёт переменные для текущего тестового сценария. См. раздел «Переменные». |
command |
plan или apply
|
Задаёт команду, которую выполнит OpenTofu: plan или apply. По умолчанию используется apply. |
plan_options |
блок | Параметры операции plan или apply. |
providers |
объект | Псевдонимы провайдеров. |
override_resource |
блок | Задаёт ресурс, который следует переопределить при запуске. |
override_data |
блок | Задаёт источник данных, который следует переопределить при запуске. |
override_module |
блок | Задаёт вызов модуля, который следует переопределить при запуске. |
Блок run.assert
Внутри блока run можно указать блоки assert, чтобы проверить состояние инфраструктуры после завершения операции apply или plan. Теоретического ограничения на количество определяемых блоков нет.
Для каждого блока требуются следующие два атрибута:
condition— это условие OpenTofu, которое должно вернутьtrue, чтобы тест прошёл, илиfalse, чтобы тест завершился неудачно. Условие должно ссылаться на ресурс, источник данных, переменную, выходное значение или модуль из основного кода, иначе OpenTofu откажется запускать тест.error_message— строка с пояснением того, что произошло при неудачном прохождении теста.
Например, можно написать блок assert следующим образом:
- main.tftest.hcl
- main.tf
run "test" {
assert {
condition = file(local_file.test.filename) == "Hello world!"
error_message = "Incorrect content in ${local_file.test.filename}."
}
}resource "local_file" "test" {
filename = "${path.module}/test.txt"
content = "Hello world!"
}Обратите внимание: условия позволяют выполнять только базовые проверки текущего состояния OpenTofu и использовать функции OpenTofu. Нельзя напрямую определять дополнительные источники данных в тестовом коде. Чтобы обойти это ограничение, можно использовать блок module для загрузки вспомогательного модуля.
Блок run.module
В некоторых случаях инструментов, предоставляемых выражением условия, может быть недостаточно, чтобы проверить, правильно ли ваш код создал инфраструктуру.
С помощью блока module можно переопределить основной модуль, который загружает tofu test. Это позволяет создавать дополнительные ресурсы или источники данных и использовать их в условиях assert.
Синтаксис похож на загрузку модулей в обычном коде OpenTofu:
run "test" {
module {
source = "./some-module"
}
}Блок module имеет следующие два атрибута:
- Атрибут
sourceуказывает на каталог загружаемого модуля или любой другой источник модуля. - Атрибут
versionзадаёт версию используемого модуля.
В блок module нельзя напрямую передавать параметры, как это обычно делается в коде OpenTofu. Вместо этого используйте блок variables, чтобы передать параметры модулю.
В этом примере проекта файл main.tf создаёт контейнер Docker с образом nginx, доступным через порт 8080. Файл main.tftest.hcl должен проверить, действительно ли веб-сервер запускается корректно, но без вспомогательного модуля выполнить такую проверку невозможно.
Чтобы создать источник данных http, файл main.tftest.hcl загружает модуль test-harness. Затем тестовый вспомогательный модуль загружает основной модуль и добавляет источник данных для проверки HTTP-ответа. Обратите внимание: источник данных в test-harness имеет явную зависимость от module.main, чтобы он возвращал результат только после завершения работы основного модуля.
- main.tf
- main.tftest.hcl
- test-harness/helper.tf
terraform {
required_providers {
docker = {
source = "kreuzwerker/docker"
version = "3.0.2"
}
}
}
resource "docker_container" "webserver" {
name = "nginx-test"
image = "nginx"
ports {
internal = 80
external = 8080
}
}run "http" {
# Load the test helper instead of the main module:
module {
source = "./test-harness"
}
# Check if the webserver returned an HTTP 200 status code:
assert {
condition = data.http.test.status_code == 200
error_message = "Incorrect status code returned: ${data.http.test.status_code}"
}
}# Load the main module:
module "main" {
source = "../"
}
# Fetch the website so the assert can do its job:
data "http" "test" {
url = "http://localhost:8080"
# Important! Wait for the main module to finish:
depends_on = [module.main]
}В этом проекте для запуска контейнера используется сторонний провайдер. Его можно запустить локально, если у вас установлен Docker Engine.
Блоки variables и run.variables
Тестируемый код (например, main.tf) часто содержит блоки переменных, значения которых нужно задать в тестовом сценарии. Переменные для запуска теста можно передать любым из следующих способов:
| Порядок | Источник |
|---|---|
| 1 | Переменные среды с префиксом TF_VAR_. |
| 2 | Файлы tfvar, указанные в текущем каталоге: terraform.tfvars и *.auto.tfvars. |
| 3 | Файлы tfvar, указанные в каталоге тестов: tests/terraform.tfvars и tests/*.auto.tfvars. |
| 4 | Переменные командной строки, заданные с помощью флага -var, и переменные из файлов, указанных с помощью флага -var-file. |
| 5 | Переменные из блока variables в тестовом файле. |
| 6 | Переменные из блока variables в блоке run. |
OpenTofu обрабатывает переменные в указанном выше порядке, поэтому последующие значения могут переопределять переменные, заданные ранее. Например:
- main.tftest.hcl
- main.tf
# First, set the variable here:
variables {
name = "OpenTofu"
}
run "basic" {
assert {
condition = output.greeting == "Hello OpenTofu!"
error_message = "Incorrect greeting: ${output.greeting}"
}
}
run "override" {
# Override it for this test case only here:
variables {
name = "OpenTofu user"
}
assert {
condition = output.greeting == "Hello OpenTofu user!"
error_message = "Incorrect greeting: ${output.greeting}"
}
}variable "name" {}
output "greeting" {
value = "Hello ${var.name}!"
}Выходные значения блока run для переменных
Также можно использовать выходные значения модуля из блока run, выполненного ранее, чтобы задать значения variables для другого блока run.
Это может быть полезно, если нужно передавать значения между разными тестовыми сценариями.
- main.tftest.hcl
- mod/main.tf
run "setup" {
module {
source = "./setup"
}
}
run "test" {
variables {
filename_from_setup = run.setup.filename
}
# more assertions to run
}output "filename" {
value = "some_file.txt"
}Ссылки между запусками (например, run.setup.filename) разрешаются только после блоков run, использующих command = apply (по умолчанию). Блоки запуска с command = plan не заполняют состояние запуска, необходимое для использования ссылок run.* в последующих блоках. Если нужно передавать выходные значения между блоками запуска, убедитесь, что в блоке, формирующем эти значения, используется command = apply. Подробнее см. #3754.
Список run.expect_failures
Вы можете использовать expect_failures внутри блока run для проверки пользовательских условий, таких как предусловия и постусловия, или правил проверки входных переменных.
Например, приведённый ниже тестовый случай проверяет, что проверка входной переменной instances корректно завершается ошибкой, если ей задано отрицательное число:
- main.tftest.hcl
- main.tf
run "main" {
command = plan
variables {
instances = -1
}
expect_failures = [
var.instances,
]
}variable "instances" {
type = number
validation {
condition = var.instances >= 0
error_message = "The number of instances must be positive or zero"
}
}Пример ниже проверяет, что некорректно настроенная проверка работоспособности завершается ошибкой. Это гарантирует, что проверка работоспособности не всегда проходит успешно, даже если она выполняется для неправильной конечной точки.
- main.tftest.hcl
- main.tf
run "test-failure" {
variables {
# This healthcheck endpoint won't exist:
health_endpoint = "/nonexistent"
}
expect_failures = [
# We expect this to fail:
check.health
]
}variable "health_endpoint" {
default = "/"
}
terraform {
required_providers {
docker = {
source = "kreuzwerker/docker"
version = "3.0.2"
}
}
}
resource "docker_container" "webserver" {
name = ""
image = "nginx"
rm = true
ports {
internal = 80
external = 8080
}
}
check "health" {
data "http" "www" {
url = "http://localhost:8080${var.health_endpoint}"
depends_on = [docker_container.webserver]
}
assert {
condition = data.http.www.status_code == 200
error_message = "Invalid status code returned: ${data.http.www.status_code}"
}
}Аргумент expect_failure предназначен только для тестирования ошибок пользовательских условий, заданных в конфигурации. Он не проверяет проблемы, обнаруженные логикой валидации внутри провайдеров.
Настройка run.command и блок run.plan_options
По умолчанию tofu test использует tofu apply для создания реальной инфраструктуры. В некоторых случаях, например если реальная инфраструктура очень дорога или её невозможно использовать для тестирования, может быть полезно вместо этого запускать только tofu plan. С помощью настройки command = plan можно выполнить планирование вместо применения. В следующем примере проверяется, что переменная правильно передаётся ресурсу docker_image, при этом план фактически не применяется:
- main.tftest.hcl
- main.tf
run "test" {
command = plan
plan_options {
refresh = false
}
variables {
image_name = "myapp"
}
assert {
condition = docker_image.build.name == "myapp"
error_message = "Missing build resource"
}
}variable "image_name" {
default = "app"
}
terraform {
required_providers {
docker = {
source = "kreuzwerker/docker"
version = "3.0.2"
}
}
}
resource "docker_image" "build" {
name = var.image_name
build {
context = "."
}
}Независимо от настройки command можно использовать блок plan_options, чтобы указать следующие дополнительные параметры для обоих режимов:
| Имя | Описание |
|---|---|
| mode | Измените этот параметр с normal (по умолчанию) на refresh-only, чтобы только обновить локальное состояние на основе удалённой инфраструктуры. |
| refresh | Задайте для этого параметра значение false, чтобы отключить проверку внешних изменений относительно файла состояния. Аналогично tofu plan -refresh=false. |
| replace | Принудительно замените указанный список ресурсов, например [docker_image.build] в примере выше. Аналогично tofu plan -replace=docker_image.build. |
| target | Ограничьте планирование указанным списком модулей или ресурсов. Аналогично tofu plan -target=docker_image.build. |
Эти параметры можно использовать вместе с переопределениями провайдеров для создания полностью автономных тестов. Пример см. в разделе «Провайдеры» ниже.
Блок providers
В некоторых случаях может потребоваться переопределить настройки провайдера для тестовых запусков. Можно использовать блоки provider вне блока run, чтобы задать дополнительные параметры конфигурации провайдеров, например учётные данные тестовой учётной записи.
provider "aws" {
// Add additional settings here
}Эта возможность также позволяет выполнять частично или полностью автономные тесты, если провайдер поддерживает такую работу. Следующий пример демонстрирует полностью автономный тест с провайдером AWS и ресурсом корзины S3:
- main.tftest.hcl
- main.tf
// Configure the AWS provider to run fake credentials and without
// any validations. Not all providers support this, but when they
// do, you can run fully offline tests.
provider "aws" {
access_key = "foo"
secret_key = "bar"
skip_credentials_validation = true
skip_region_validation = true
skip_metadata_api_check = true
skip_requesting_account_id = true
}
run "test" {
// Run in plan mode to skip applying:
command = plan
// Disable the refresh to prevent reaching out to the AWS API:
plan_options {
refresh = false
}
// Test if the bucket name is correctly passed to the aws_s3_bucket
// resource:
variables {
bucket_name = "test"
}
assert {
condition = aws_s3_bucket.test.bucket == "test"
error_message = "Incorrect bucket name: ${aws_s3_bucket.test.bucket}"
}
}variable "bucket_name" {}
provider "aws" {
region = "us-east-2"
}
resource "aws_s3_bucket" "test" {
bucket = var.bucket_name
}Псевдонимы провайдеров
Помимо переопределения провайдеров, можно назначать им псевдонимы, чтобы заменить их другим провайдером в блоке run. Это полезно, если в одном тестовом файле нужно иметь две конфигурации провайдера и переключаться между ними.
В приведённом ниже примере тестовый случай sockettest загружает конфигурацию другого провайдера Docker, чем остальные части файла.
- main.tftest.hcl
- main.tf
# This is the default "docker" provider for this file:
provider "docker" {
host = "tcp://0.0.0.0:2376"
}
# This will be the override:
provider "docker" {
alias = "unixsocket"
host = "unix:///var/run/docker.sock"
}
run "sockettest" {
# Replace the "docker" provider for this test case only:
providers = {
docker = docker.unixsocket
}
assert {
condition = docker_image.build.name == "myapp"
error_message = "Missing build resource"
}
}
// Add other tests with the original provider here.terraform {
required_providers {
docker = {
source = "kreuzwerker/docker"
version = "3.0.2"
}
}
}
resource "docker_image" "build" {
name = "myapp"
build {
context = "."
}
}Ссылки на выходные значения и переменные модуля run в блоках provider
В блоках provider можно ссылаться на var (переменные) и выходные значения модулей блока run, чтобы настраивать тестовые провайдеры на основе динамической конфигурации.
variables {
region = "us-west-2"
}
provider "aws" {
region = var.region
access_key = run.setup.access_key
secret_key = run.setup.secret_key
}
run "setup" {
# `mod` module has outputs access_key and secret_key
module {
source = "./mod"
}
# Actual run block behavior, such as asserts, are skipped for simplicity
}
Блоки mock_provider
Блок mock_provider позволяет заменить конфигурацию провайдера конфигурацией-заглушкой. В этом случае создание и получение ресурсов и источников данных провайдера пропускаются. Вместо этого OpenTofu автоматически генерирует все вычисляемые атрибуты и блоки для использования в тестах.
Подробнее о том, как OpenTofu создаёт автоматически сгенерированные значения.
Для фиктивных провайдеров поддерживаются поля alias и for_each. Однако атрибут for_each поддерживается только при использовании также alias. Сочетание этих двух параметров позволяет использовать экземпляры провайдера в наборе тестов.
Фиктивные провайдеры также поддерживают блоки mock_resource и mock_data. В некоторых случаях вместо автоматически сгенерированных значений могут понадобиться значения по умолчанию. Для этого передайте их в поле defaults блоков mock_resource или mock_data.
Кроме того, можно использовать блоки override_resource и override_data для переопределения ресурсов или источников данных в рамках одного провайдера. Подробнее о переопределении см. в следующем разделе.
В приведённом ниже примере мы проверяем, что имя корзины правильно передаётся ресурсу, не создавая её фактически:
- main.tftest.hcl
- main.tf
// All resources and data sources provided by `aws.mock` provider
// will be mocked. Their values will be automatically generated.
mock_provider "aws" {
alias = "mock"
}
// The same goes for `local` provider. Also, every `local_file`
// data source will have its `content` set to `test`.
mock_provider "local" {
mock_data "local_file" {
defaults = {
content = "test"
}
}
}
// Test if the bucket name is correctly passed to the aws_s3_bucket
// resource from the local file.
run "test" {
// Use `aws.mock` provider for this test run only.
providers = {
aws = aws.mock
}
assert {
condition = aws_s3_bucket.test.bucket == "test"
error_message = "Incorrect bucket name: ${aws_s3_bucket.test.bucket}"
}
}data "local_file" "bucket_name" {
filename = "bucket_name.txt"
}
provider "aws" {
region = "us-east-2"
}
resource "aws_s3_bucket" "test" {
bucket = data.local_file.bucket_name.content
}Блоки override_resource и override_data
В некоторых случаях может потребоваться протестировать инфраструктуру с переопределёнными ресурсами или источниками данных. Можно использовать блоки override_resource или override_data, чтобы пропустить создание и получение этих ресурсов или источников данных с помощью реального провайдера. Вместо этого OpenTofu автоматически сгенерирует все вычисляемые атрибуты и блоки для использования в тестах.
Подробнее о том, как OpenTofu создаёт автоматически сгенерированные значения.
Эти блоки состоят из следующих элементов:
| Имя | Тип | Описание |
|---|---|---|
| target | ссылка | Обязательный параметр. Адрес целевого ресурса или источника данных, который нужно переопределить. |
| values | объект | Пользовательские значения вычисляемых атрибутов и блоков, используемые вместо автоматически сгенерированных. |
Блоки override_resource или override_data можно использовать для всего тестового файла или внутри отдельного блока run. Если оба блока заданы для одного и того же target, приоритет имеет последний.
В приведённом ниже примере мы проверяем, что имя корзины правильно передаётся ресурсу, не создавая её фактически:
- main.tftest.hcl
- main.tf
// This data source will not be called for any run
// in this `.tftest.hcl` file. Instead, `values` object
// will be used to populate `content` attribute. Other
// attributes and blocks will be automatically generated.
override_data {
target = data.local_file.bucket_name
values = {
content = "test"
}
}
// Test if the bucket name is correctly passed to the aws_s3_bucket
// resource from the local file.
run "test" {
// S3 bucket will not be created in AWS for this run,
// but it's available to use in both tests and configuration.
override_resource {
target = aws_s3_bucket.test
}
assert {
condition = aws_s3_bucket.test.bucket == "test"
error_message = "Incorrect bucket name: ${aws_s3_bucket.test.bucket}"
}
}data "local_file" "bucket_name" {
filename = "bucket_name.txt"
}
provider "aws" {
region = "us-east-2"
}
resource "aws_s3_bucket" "test" {
bucket = data.local_file.bucket_name.content
}Нельзя использовать override_resource или override_data с одним экземпляром ресурса или источника данных. Необходимо переопределить каждый экземпляр ресурса или источника данных.
Автоматически сгенерированные значения
Для создания заглушек ресурсов и источников данных OpenTofu должен автоматически генерировать вычисляемые атрибуты, не вызывая соответствующие провайдеры. При создании этих значений OpenTofu не может следовать пользовательской логике провайдера, поэтому использует простые правила, основанные на типе значения:
| Тип атрибута | Сгенерированное значение |
|---|---|
| number | 0 |
| bool | false |
| string | Случайная буквенно-цифровая строка. |
| list | Пустой список. |
| map | Пустая карта. |
| set | Пустое множество. |
| object | Объект, поля которого заполняются рекурсивно с использованием той же логики. |
| tuple | Пустой кортеж. |
Вместо автоматически сгенерированных значений можно задать пользовательские значения в соответствующих полях заглушек или переопределений. Учтите, что это возможно только для вычисляемых атрибутов, а значения конфигурации изменить нельзя.
Блок override_module
В некоторых случаях может потребоваться протестировать инфраструктуру с переопределёнными вызовами модулей. Можно использовать блок override_module, чтобы игнорировать всю конфигурацию, предоставленную вызываемым модулем. В этом случае OpenTofu будет использовать пользовательские значения, указанные в блоке override_module, в качестве выходных значений модуля.
Блок состоит из следующих элементов:
| Имя | Тип | Описание |
|---|---|---|
| target | ссылка | Обязательный параметр. Адрес целевого вызова модуля, который нужно переопределить. |
| outputs | объект | Значения, используемые в качестве выходных значений вызова модуля. Если выходное значение не указано, OpenTofu по умолчанию задаст для него null. |
Блок override_module можно использовать для всего тестового файла или внутри отдельного блока run. Если оба блока заданы для одного и того же target, приоритет имеет последний.
В приведённом ниже примере мы проверяем, что имя корзины правильно передаётся из модуля, не вызывая его фактически:
- main.tftest.hcl
- main.tf
- bucket_meta/main.tf
// All the module configuration will be ignored for this
// module call. Instead, the `outputs` object will be used
// to populate module outputs.
override_module {
target = module.bucket_meta
outputs = {
name = "test"
tags = {
Environment = "Test Env"
}
}
}
// Test if the bucket name is correctly passed to the aws_s3_bucket
// resource from the module call.
run "test" {
// S3 bucket will not be created in AWS for this run,
// but it's available to use in both tests and configuration.
override_resource {
target = aws_s3_bucket.test
}
assert {
condition = aws_s3_bucket.test.bucket == "test"
error_message = "Incorrect bucket name: ${aws_s3_bucket.test.bucket}"
}
assert {
condition = aws_s3_bucket.test.tags["Environment"] == "Test Env"
error_message = "Incorrect `Environment` tag: ${aws_s3_bucket.test.tags["Environment"]}"
}
}module "bucket_meta" {
source = "./bucket_meta"
}
provider "aws" {
region = "us-east-2"
}
resource "aws_s3_bucket" "test" {
bucket = module.bucket_meta.name
tags = module.bucket_meta.tags
}data "local_file" "bucket_name" {
filename = "bucket_name.txt"
}
output "name" {
value = data.local_file.bucket_name.content
}
output "tags" {
value = {
Environment = "Dev"
}
}Нельзя использовать override_module для одного экземпляра вызова модуля. Необходимо переопределить каждый экземпляр вызова модуля.
Copyright (c) The OpenTofu Authors
Copyright (c) 2014 HashiCorp, Inc.
Mozilla Public License, version 2.0
https://opentofu.org/docs/v1.12/cli/commands/test/