# Compatibility Testing Pulumi HCL

DevFeed: [Compatibility Testing Pulumi HCL](<https://devfeed.tech/articles/compatibility-testing-pulumi-hcl-18993.md>)

Original publisher: [Read original article](<https://www.pulumi.com/blog/compatibility-testing-pulumi-hcl/>)

Author: Ian Wahbe

Published: 2026-08-14T00:00:00Z

Content type: tutorial

Language: en

Sources: [Pulumi](<https://devfeed.tech/sources/pulumi.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [opentofu](<https://devfeed.tech/topics/opentofu.md>), [Terraform](<https://devfeed.tech/topics/terraform.md>), [terraform provider](<https://devfeed.tech/topics/terraform-provider.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [hcl](<https://devfeed.tech/tags/hcl.md>), [opentofu](<https://devfeed.tech/tags/opentofu.md>), [terraform](<https://devfeed.tech/tags/terraform.md>), [terraform-provider](<https://devfeed.tech/tags/terraform-provider.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

The article explains a compatibility-testing approach for Pulumi HCL. It defines correctness as Pulumi HCL and OpenTofu generating the same Terraform provider steps from the same HCL program, then describes tests that compare provider configuration and RPC behavior.

## Source excerpt

Pulumi HCL has at its core a simple promise: A program that works for tofu apply will also work for pulumi up. This must be true to allow Terraform modules to be shared between tofu config and Pulumi programs. This property makes testing Pulumi HCL simple. Let me explain. At the end of the day, Pulumi is a system to translate actual state & desired state into a series of imperative actions, so actual state can be reconciled to desired state. Terraform is a system to translate actual state & desired state into a series of imperative actions, so actual state can be reconciled to desired state. How desired state is expressed can be radically different, and the underlying reconciliation engine can be radically different, but at the end of the day, both tools do the same thing: Executing a Terraform program looks like this: flowchart LR tf["*.tf files"] current["current state"] subgraph engine["reconciliation engine"] direction LR desired["desired state"] --> internal["provider steps"] end output["provider steps"] tf --> desired current --> engine engine --> output Executing a Pulumi program is more dynamic, because the reconciliation engine is in more active dialog with the user's program. That said, the diagram is the same shape. To match semantics, Pulumi HCL dynamically bridges any Terraform provider in the registry. This means that, for the subset of Pulumi programs that are valid OpenTofu programs, both programs take the same input (*.tf files) and produce the same step output (Terraform provider steps). Providers are the part of our model that generates user-observable behavior, which means if we match what providers see, we match what users see. This gives us a really nice definition of correctness for Pulumi HCL1: Pulumi HCL correctly interprets an HCL program when it generates the same set of provider steps as tofu does. If you are familiar with property-based testing, you might be thinking this looks like a testable property. You're right. How we compatibility