Have you considered splitting terratest up? #1492
Comments
|
Thank you for taking the time to share your feedback and thoughtful suggestions! We’re thrilled to hear that you’re finding TerraTest valuable and that it’s helping with your AWS Lambda testing. We completely understand your concerns about dependency bloat and the challenges of auditing, managing vulnerabilities, and ensuring compliance. Interestingly, I came across this PR that attempted a similar approach in the past. The main challenge with implementing this change is ensuring backward compatibility. Splitting the modules would require a major version update and comprehensive migration documentation to minimize disruption for existing users. That said, this is a valuable idea we can add to our backlog and consider implementing as part of a future major release, such as version 1.x.x. A prototype PR showcasing this approach would also be greatly appreciated, as it would allow us to explore and evaluate the feasibility of the idea further. We hope this makes sense and look forward to hearing your thoughts! |
Hello 👋🏻
Firstly I'd like to say thank you for making this, it really is incredibly powerful and super useful! Please take everything below from the point of view of "I love this tool, but it could be even better/easier to adopt if..."
I know it's a big ask and not likely to happen anytime soon (or even at all). But I have a simple Terraform module for an AWS Lambda Function that I'm using TerraTest to write tests for (and loving!).
It's a bit of a PoC for using TerraTest so the test itself is super simple for now it simply deploys the lambda and checks the outputs are as expected (effectively a "does this even deploy" smoke test). So you can imagine the test is very simple.
The imports in my test file are as follows:
You can see it's not exactly extensive. But my
go.modhowever is full of dependencies I do not need including:Click me for the full `go.mod` 👇🏻
This seems like a lot of dependencies, which is totally understandable as TerraTest is capable of testing a lot of different infrastructures and ecosystems.
It strikes me though that this should be a little more "opt in" IMO. i.e. if I'm testing a Terraform module that deploys an AWS Lambda Function my
go.modshould look a bit more like this:As I don't need any kubernetes or openapi stuff. If I did, I'd like the ability to now depend on e.g.
github.com/gruntwork-io/terratest-k8sand/orgithub.com/gruntwork-io/terratest-openapiand bring those things in only when I need them.Each one of these dependencies is something I have to audit, check the security status of, keep up to date, justify the need for and defend any open unpatched CVEs etc.
It seems there are a few others with similar issues (although not all relevant):
Describe the solution you'd like
I'd like
terratest/modulesto be split out into a number of separate packages, each responsible for a specific area of concern so that by importing say the aws one, you don't end up depending on k8s packages or openapi.So instead of
import "github.com/gruntwork-io/terratest/modules/terraform"you'd haveimport "github.com/gruntwork-io/terratest-terraform"Describe alternatives you've considered
None really, I guess just live with the dependency bloat? But it does make adoption more difficult if you first have to justify all these additional packages/potential vulnerabilities that you have no actual need for, they just come along for the ride with things you do need
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: