Terraform has become an essential tool for infrastructure-as-code practitioners, enabling efficient and repeatable provisioning of cloud resources. Recently, the terraform test command has added a new dimension to this, allowing developers to validate their modules with confidence. However, as with any new feature, some rough edges emerge, and one, in particular, is causing headaches: handling file path slashes (/ vs. ) across different operating systems.

This seemingly small issue complicates efforts to create portable, reusable workflows for terraform test, particularly in diverse environments. Let’s dive into the problem, explore its impact, and propose a solution.

Make File Paths OS Agnostic

Terraform has become an essential tool for infrastructure-as-code practitioners, enabling efficient and repeatable provisioning of cloud resources. Recently, the terraform test command has added a new dimension to this, allowing developers to validate their modules with confidence. However, as with any new feature, some rough edges emerge, and one, in particular, is causing headaches: handling file path slashes (/ vs. ) across different operating systems.

This seemingly small issue complicates efforts to create portable, reusable workflows for terraform test, particularly in diverse environments. Let’s dive into the problem, explore its impact, and propose a solution.

Can You Spot the Difference?

Consider these two commands:

terraform test -filter='tests/azure-fn-app-stand-alone.tftest.hcl' -var-file='./tests/.debug-test.tfvars' -verbose

Here’s the second:

terraform test -filter='tests\azure-fn-app-stand-alone.tftest.hcl' -var-file='./tests/.debug-test.tfvars' -verbose

At a glance, they seem almost identical. The only discernible difference is the direction of the slashes in the -filter path. But when executed, the results tell two very different stories.

The first command, using forward slashes (/), produces this output:

Success! 0 passed, 0 failed.

Meanwhile, the second command, using backslashes (), results in the following:

tests\azure-fn-app-stand-alone.tftest.hcl... in progress

blah blah blah

tests\azure-fn-app-stand-alone.tftest.hcl... tearing down
tests\azure-fn-app-stand-alone.tftest.hcl... pass

Success! 2 passed, 0 failed.

Clearly, the choice of slashes affects how terraform test interprets file paths. While the issue might seem minor, it introduces friction for developers trying to ensure their tests run consistently across different environments.

The Official Documentation

The Terraform documentation acknowledges this discrepancy, outlining recommended syntax based on the operating system:

Linux, Mac OS, and UNIX:

terraform test -filter=tests/validations.tftest.hcl

PowerShell:

terraform test -filter='tests\validations.tftest.hcl'

Windows cmd.exe:

terraform test -filter=tests\validations.tftest.hcl

While this guidance is helpful in straightforward setups, it falls short in more complex environments. What happens when you’re running a Windows VM on a MacBook Pro via Parallels? Or when you’re scripting these commands for execution in CI/CD pipelines, where the worker agent’s operating system may vary? The ambiguity creates unnecessary challenges for developers.

The Real Problem: Portability and Automation

The issue becomes particularly thorny when building scripts or workflows around the terraform test command. A developer might write a script using forward slashes, only to have it fail on a Windows-based CI/CD pipeline. Conversely, scripts using backslashes might fail in Linux containers.

This lack of uniformity hampers the ability to share scripts with the broader community. Developers shouldn’t have to worry about which direction the slashes go when collaborating or deploying workflows. For example:

  • Pipeline tools like Azure DevOps Pipelines, GitHub Actions, or Jenkins may run on worker agents with different OSes.
  • Hybrid development setups, such as Windows Subsystem for Linux (WSL) on Windows or Parallels on macOS, blur the line between traditional platform conventions.

Ultimately, the burden of ensuring the correct slash direction should not fall on developers or infrastructure engineers. Terraform is designed to simplify infrastructure management; this issue runs counter to that ethos.

The Feature Request: A Simple Solution

What if the terraform test command could automatically detect and normalize file paths? By interpreting both forward slashes (/) and backslashes () based on the operating system it’s running on, Terraform could eliminate this inconsistency.

This feature would:

  • Enhance portability: Scripts and commands would work seamlessly across different platforms.
  • Streamline workflows: Developers could focus on writing tests, not debugging file path issues.
  • Support automation: CI/CD pipelines would be more robust, with fewer OS-specific tweaks required.

Such functionality would align with Terraform’s goal of simplifying infrastructure-as-code practices. Many tools, from Git to Docker, already handle file paths intelligently. Terraform should be no exception.

Conclusion

The terraform test command is a powerful addition to the Terraform ecosystem, enabling developers to validate their modules with precision. However, its current behavior around file path slashes creates an unnecessary obstacle for those striving to write reusable scripts and workflows.

By implementing a feature to handle both forward and backslashes automatically, HashiCorp could remove this barrier and empower developers to focus on what matters: delivering reliable, portable infrastructure-as-code. Let’s make terraform test truly seamless, regardless of the platform it’s running on.