This message was deleted.

Hi Sahil, we do Terraform testing in the pipeline using Terratest and golang, Usually it uses one of the examples that we keep within the module and goes through a set of assertions to verify if the module creates the resources as expected. Once we develop a feature and create a PR, a pipeline will be triggered automatically to run the go tests and ensures that the new feature is not breaking anything. The guys in Cloudposse are doing something similar here https://github.com/cloudposse/terraform-aws-eks-cluster/blob/main/test/src/examples_complete_test.go .

@Ahmed Mourad Thankyou very much for your reply. That makes sense and I am aware about about terratest and writing tests in go. What I was after was let’s say you have Module A and that has version 1.0.0. We have 3/10 terraform stacks (root terraform modules) that are calling this Module A. If we make an update to Module A version 1.0.1 what mechanism can we implement to say Module A is consumed in these 3 terraform stacks - so let me run tests/ a form of regression test for those stacks only to ensure that the changes I’ve made to the module still works in the context of my stacks and doesn’t break anything So my thinking is yes it is possible to build a custom script that upon a PR merge we can source all stacks that make this module call by filtering for the source = < module source >. And then execute tests against those stacks that call it. (Much easier if you are operating in a monorepo!) Was just wondering if there was an existing tool out there to support for such a workflow Hope i made sense :)

I got your point now, I'm not aware that there is a tool to help with that, and I guess I would do it the same way you suggested by allowing the pipeline to source the consumed modules and run the tests. Although it might be challenging for me because it's not a monorepo

Hi Sahil, I just ran into your question. We did some Terraform tests in the past, so maybe I'll be able to help 🙂

what mechanism can we implement to say Module A is consumed in these 3 terraform stacks - so let me run tests/ a form of regression test for those stacks only to ensure that the changes I’ve made to the module still works in the context of my stacks and doesn’t break anything

This seems as if you wanted to run tests of your dependency (The Terraform Module A) against the other 3 Terraform projects that use that dependency. Wouldn't it be enough to test the Terraform Module A separately, and then ensure that the other 3 Terraform projects use the well-tested version of the Terraform Module A?