Terraform tests being skipped

Terraform
1

Hello,

I’m testing a terraform module I developed with terraform test. The module is installing a chart helm over a gcp Kubernetes cluster.

In the setup, I create the Kubernetes cluster.

In my run blocks, I do checks on the proper install of the tested module.

tests/my.tftest.hcl... in progress

run "setup_tests"... pass

run "compute_names"... skip

run "helm_release"... skip

tests/my.tftest.hcl... tearing down

tests/my.tftest.hcl... pass

Success! 1 passed, 0 failed, 3 skipped.

As we can see in the output, the cluster is successfully created: “pass” for setup_tests.
On the contrary, the below tests are marked as skipped - although I want them to run, and did not on purpose make them skip.

The structure of my module and tests is described below:

image
image1377×793 50.2 KB

Content of main.tf:

data “google_client_config” “default” {}

module “cluster” {
parameters of the cluster…

}

outputs: google_client_config, cluster certificate, … etc

Content of my.tftest.hcl:

run “setup_tests” {

module {

source = "./tests/setup"

}

}

4 provider blocks: google, kubernetes, helm, kubectl with parameters fed with the output of main.tf: google_client_config, cluster certificate, … etc

Then: run blocks, with plan or apply command and assertions on the cluster

All my run blocks are being skipped, even the most simple one.

Any idea of what is causing this behavior?

Thanks

2

Hi @guilhem-martin, run blocks would be skipped if there was an error in a preceding run block, or in a variable or provider that the run block depends on.

Is there nothing else anywhere in the output that suggests an error has occurred? If there definitely isn’t, could you file this as a bug in GitHub · Where software is built?

Thanks!

1 Like
3

thanks @liamcervante

no error shows up.

Between the setup_tests run block and the first run_block, there are the declarations of the 4 providers. Let me try to put one run block independent from the providers above, maybe it could reveal what is making the call fails - if the order of execution of the file is done from up to down, including providers.
I keep you posted.

4

update: so even by putting a run block (that doesn’t require any provider) above the providers declaration, it’s still skipped.

5

@liamcervante I’ll try to setup a minimalist example of the failure before to create the issue.
Thanks.

6

this is what gpt5 tells me after giving it the TF_LOG=DEBUG few lines of output when the tests are skipped:

your test runs are skipped because the provider blocks in your test file reference run.setup_tests.* values. In Terraform tests, run.* expressions are only valid inside a run block. Top‑level provider blocks are evaluated before any run executes, so those references can’t be resolved and Terraform skips the subsequent runs.

How to fix Pick one of these patterns:

Use a kubeconfig file (recommended)
Have setup write a kubeconfig to a known path.
Configure providers in the test file to load that kubeconfig using a static path (no run.*)

not sure whether this is relevant or not.

7

update: dumping the kubernetes connection information to a file and retrieving the content of the file within the tftest.hcl produced the same behavior with the tests being skipped

8

@liamcervante

I finally figured out how to make it work.

Here’s how I did:

 1. at the beginning of the tftest.hcl, declaring the gcp provider and its variable

  1. then calling the setup module
    run “setup_tests” {

    module {

    source = "./tests/setup"

    }

    }
    The setup module creates a Kubernetes infrastructure

  2. then, I declare the other providers: kubectl, helm_release… that feeds from the outputs of the setup module (certificate, host) and also from the google_config client data defined in the setup module

My main issue was finally a matter of ordering the providers initialization order, as well as where to place them (tftest.hcl vs setup terraform).

I guess an output error from the providers that were failing would have helped.

Thanks again for the help @liamcervante

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.