Spec-Zone.ru › OpenTofu 1.12

Команда: 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. Теоретического ограничения на количество определяемых блоков нет.

Для каждого блока требуются следующие два атрибута:

  1. condition — это условие OpenTofu, которое должно вернуть true, чтобы тест прошёл, или false, чтобы тест завершился неудачно. Условие должно ссылаться на ресурс, источник данных, переменную, выходное значение или модуль из основного кода, иначе OpenTofu откажется запускать тест.
  2. 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/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API