We have a terraform module that creates AWS RDS instances. We are using terraform test to test that module for which we have 5 run blocks.
I note that terraform 1.12 now has the ability to run tests in parallel so I’ve been playing around with that. Simply from examining behaviour on the AWS console I’ve observed something that seems strange. In a nutshell, the creation of resources seems to happen in parallel but the teardown seems to still be sequential. Hopefully screenshots will help explain.
When I run my 5 tests (all of which create a primary, 4 of which create a replica) they’ll all getting created at the same time (i.e. in parallel):
The teardown though seems sequential as these screenshots suggest:
As you can see, all the instances are getting deleted one at a time.
Is this expected behaviour? Why doesn’t terraform teardown all instances at the same time?
Inexplicably by parallelizing my tests they’re not actually completing any quicker, total execution time both before and after parallelizing is around about 57 minutes. Given all the instances are being created simultaneously I can’t understand this, but clearly the sequential teardown isn’t helping. I can observe from the GitHub Actions logs that the teardown begins at about 23 minutes.
Can anyone shed any light on why teardown seems to be sequential instead of parallelized?
Thanks in advance
I would guess it could just be an oversight? But would probably be a good idea to file a GitHub issue.
I noticed in my use case (unit tests only, which already run very quickly), with parallel run was slightly slower than without… this is not uncommon with test frameworks when you’re running a small number of tests.
I did file an issue requesting some additional stats / debug logging around parallel execution, since currently, I think it is pretty hard to tell when it’s successfully using parallel execution at all.
1 Like
Thank you very much. I’ve added a comment to your issue.
As far as teardown in parallel, that’s probably a good thing to file a separate issue about too, since fixing it would presumably be somewhat more urgent than improving logging / debugging.
I’ve dug in to the logs to find out where things are slowing down.
Here are the pertinent logs from the parallel execution:
Thu, 22 May 2025 20:20:44 GMT tests/create_rds.tftest.hcl... in progress
Thu, 22 May 2025 20:42:43 GMT tests/create_rds.tftest.hcl... tearing down
Thu, 22 May 2025 21:19:37 GMT tests/create_rds.tftest.hcl... pass
and these from the sequential execution:
Fri, 23 May 2025 07:51:45 GMT tests/create_rds.tftest.hcl... in progress
Fri, 23 May 2025 08:38:23 GMT tests/create_rds.tftest.hcl... tearing down
Fri, 23 May 2025 08:47:10 GMT tests/create_rds.tftest.hcl... pass
So:
|
parallel |
sequential |
| running the tests |
19m59s |
46m38s |
| teardown |
36m54s |
8m47s |
|
56m53s |
55m25s |
Clearly running in parallel has caused the tests to speed up but the wall clock time has increased!
I have a theory about what’s going on here, let me explain. Those 5 tests all create an RDS instance and 4 of them also create a replica so that’s 9 instances in total.
- I already know that the teardown is occurring sequentially so we can deduce that’s ~4m06s per instance (i.e. 36m54s / 9).
- The teardown for the sequential execution is 8m47s which is =~ 2 * 4m06s
Therefore my theory is that when executing sequentially the tear down for each of the 5 runs occurs while the next run is executing. Hence there’s a hyperthreading effect here, something I’ve tried (rather amateurishly 
) to illustrate here
When executing in parallel the teardown for all tests occurs at the end and, because the resources are torn down sequentially, it takes a long time.
The overall effect is running tests in parallel actually causes the whole thing to take slightly longer.
This theory is supported by this annotated screenshot taken from AWS console while the tests from the sequential execution are running:
I got a useful reply on the issue: Terraform test: Is teardown parallelized? · Issue #37156 · hashicorp/terraform · GitHub
TL;DR Teardown is still sequential at the time of writing, even for parallel executions.
