The OpenTofu version tests look isolated, but they can still run whatever terraform happens to be on the developer's PATH.
The setup in newTestClientForTofu gives the client temporary bin/cache directories and a mocked downloader. The weird part is that this doesn't stop the client from discovering an existing Terraform binary outside those directories.
I can reproduce it with:
go test ./server/core/terraform/tfclient -run TestDetectVersion_Terraform_TfFileUnchanged -count=1
On a machine where terraform resolves to a broken tfenv shim, that fails with:
unexpected error: running terraform version: : exit status 1
Running the same test with the shim removed from PATH passes.
That particular test is checking version detection from a .tf file. The state of the local Terraform install shouldn't be an input to it. It also means the suite can pass in CI and fail on a developer machine for reasons that have nothing to do with the code under test.
I think the test helper should provide a controlled fake executable/version response, or otherwise isolate executable lookup so these tests can't fall through to an ambient Terraform install. The cases that intentionally test downloads can still opt into that behavior explicitly.
Basically, these should pass when Terraform is installed, missing, managed by tfenv, or completely broken.
The OpenTofu version tests look isolated, but they can still run whatever
terraformhappens to be on the developer'sPATH.The setup in
newTestClientForTofugives the client temporary bin/cache directories and a mocked downloader. The weird part is that this doesn't stop the client from discovering an existing Terraform binary outside those directories.I can reproduce it with:
go test ./server/core/terraform/tfclient -run TestDetectVersion_Terraform_TfFileUnchanged -count=1On a machine where
terraformresolves to a brokentfenvshim, that fails with:Running the same test with the shim removed from
PATHpasses.That particular test is checking version detection from a
.tffile. The state of the local Terraform install shouldn't be an input to it. It also means the suite can pass in CI and fail on a developer machine for reasons that have nothing to do with the code under test.I think the test helper should provide a controlled fake executable/version response, or otherwise isolate executable lookup so these tests can't fall through to an ambient Terraform install. The cases that intentionally test downloads can still opt into that behavior explicitly.
Basically, these should pass when Terraform is installed, missing, managed by
tfenv, or completely broken.