Terraform mock-api for unittesting tf config files

[abaki007]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Hi,

Having used various AWS API mockers to mimic and stub aws api responses for code developed to run in AWS, it got me thinking we could do something similar with Terraform.

An option for a dry-run or a testing framework, would let us verify our terraform code and give us a smaller feedback cycle on the terraform code we write. It would also let us potentially identify dependancies between resources prior to running our first apply.

This is by no means trivial but would give us the ability to test our terraform config files and modules prior to deploy. Also, running deployment of resources to validate code is very expensive.

Ofc, post deploy we have inspec but by the we've gone thru the pain of terraform plan, terraform apply, fix failure, write a make file, make plan, make apply, fix failure...

New or Affected Resource(s)

dry-run option / testing framework

Potential Terraform Configuration

References

Mocking api and libraries:

• https://github.com/spulec/moto
• https://www.npmjs.com/search?q=serverless-offline

[paultyng]

I think it would be a very large undertaking to mock enough of the AWS API to make this useful. The AWS provider has 500+ resources and data sources, there may be some overlap in terms of API endpoints but some resources may also use multiple endpoints. Its just a lot of surface area. I think really what may be the best way to implement this is a couple different things:

• More sophisticated online validation (see Add online validation capabilities (DryRun, etc.) #7888)
• Plan file introspection (ie. using the JSON format plan output).

Going to close this as I think this is more of an upstream testability concern than a provider specific implementation but please comment here if you feel I am missing some aspect of the solution you describe.

[paultyng]

You may also be able to implement this with https://localstack.cloud/

You could use a provider config like the following:

provider "aws" {
  access_key                  = "mock_access_key"
  region                      = "us-east-1"
  s3_force_path_style         = true
  secret_key                  = "mock_secret_key"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true
  version                     = "1.59.0"

  endpoints {
    apigateway     = "http://localhost:4567"
    cloudformation = "http://localhost:4581"
    cloudwatch     = "http://localhost:4582"
    dynamodb       = "http://localhost:4569"
    es             = "http://localhost:4578"
    iam            = "http://localhost:4593"
    kinesis        = "http://localhost:4568"
    lambda         = "http://localhost:4574"
    r53            = "http://localhost:4580"
    s3             = "http://localhost:4572"
    sns            = "http://localhost:4575"
    sqs            = "http://localhost:4576"
    ssm            = "http://localhost:4583"
    sts            = "http://localhost:4592"
    # firehose       = "http://localhost:4573"
    # redshift       = "http://localhost:4577"
    # secretsmanager = "http://localhost:4584"
    # ses            = "http://localhost:4579"
    # stepfunctions  = "http://localhost:4585"
  }
}

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!