I haven't used terraform test yet but would be nice to have that hook.

Also, terraform test will be GA in 1.6.0, with huge changes

This comes with a significant change in how Terraform tests are written and executed.

Terraform tests are now written within .tftest.hcl files, controlled by a series of run blocks. Each run block will execute a Terraform plan or apply command against the Terraform configuration under test and can execute conditions against the resultant plan and state.

https://github.com/hashicorp/terraform/releases/tag/v1.6.0-alpha20230802

So I propose to wait with hook implementation until TF 1.6.0 release

I'd be happy to contribute to this.

Hi @hoangelos
Glad to hear that. You can start from https://github.com/antonbabenko/pre-commit-terraform/blob/master/.github/CONTRIBUTING.md

I submitted a PR for this. There's only one problem. It would run also when .tftest.hcl files are updated too and not just .tf files. However, there's a problem with the logic of files that "assumes" that the directory the files that match is the directory you want to run the command from. This is not true with test. Also, this requires terraform 1.6.x obviously.

I haven't yet made it to employ TF tests for my use cases, hence I'm speaking more of speculatively, though I see the logic like this: 1) when any of TF Config files (tf/tfvars) are changed, run TF test if there are any TF Test files present in the directory with each changed TF Config file + 2) when any of TF Test files are changed, run TF test in the directory with each changed TF Test file (optionally with a conditional of "if there are any TF Config files present in the directory with each changed TF Test file").
Let's move discussion to #581

This is some feedback since I'm migrating from Kitchen-Terraform to Terraform test. I could see running unit tests as part of pre-commit helpful, but running what they are branding as integration tests would be far too long of a feedback loop in its current implementation. Each run tears down the infra, and subsequently, the next run needs to rebuild it. This makes integration tests unusable for almost everything we do or anything that takes longer than a few minutes.

Tests can run a command of plan == unit test or apply == integration based on the language in their blog post. This is hardcoded in the test and can't be passed in the CLI yet (I'll check for an issue and open one if not), which presents an implementation detail as far as this issue goes. I suppose we could use separate test files but that would probably be a lot of copy/paste.

Anyways, just some thoughts!