Aniruddha Maru

Done googleapis/python-storage#393

One workaround I've found for this: variables.tf ``` variable "config_a" {} ``` typed_variables.tf ``` module "config_a" { source = "./modules/type-config" input = var.config_a } ``` ./modules/type-config/variables.tf ``` variable "input" {...

It seems like this could be solved by just using [t.Cleanup](https://pkg.go.dev/testing#T.Cleanup) for both `tearDownSuite` and `tearDownTest`. Is there an obvious reason for not using cleanup? If not, I can put...

> t.Cleanup is a Go 1.14 feature, this would need us to update the go.mod to 1.14 and drop support of go 1.13. Not necessarily a bad thing, but needs...

@brackendawson looks like the only option for

@brackendawson although, [Suite.SetT](https://github.com/stretchr/testify/blob/master/suite/suite.go#L34) also got me thinking - is Suite even concurrent-safe? Because it is being run from multiple routines [here](https://github.com/stretchr/testify/blob/master/suite/suite.go#L128), and if there are multiple parallel tests within a...

> That should stop us from calling teardowns early, do you agree? Nice, yeah I think that works.

> Nice, yeah I think that works. Never mind, spoke too soon, it leads to a deadlock because parallel sub-tests [wait for](https://cs.opensource.google/go/go/+/refs/tags/go1.16.6:src/testing/testing.go;l=1059) parent test to complete, and parent test won't...

Fwiw, here's a couple of possible fixes for the tearDown ordering: 1. Group subtests under a single group within the test suite: https://github.com/stretchr/testify/compare/master...maroux:group_tests (go 1.6+) 2. Use `T.Cleanup`: https://github.com/stretchr/testify/compare/master...maroux:parallel_tests_cleanup (go...

> workable design that supports parallel testing for v2.0 I imagine the easiest way is to allow test sub-methods to have a signature like so: ``` (_ *FooSuite) test_foo(s *suite.SuiteHelper)...