How to FailNow during SetupSuite?

[AutomateAaron]

I'm writing a testing suite that spins up some resource on SetupSuite (in my case a virtual machine), runs some tests against it, then destroys the resource on TearDownSuite.

Now, sometimes the resource may fail to spin up or have some issue with it which makes running the tests useless, in which case I'd like to suite.T().FailNow(). However, if you run suite.T().FailNow() during SetupSuite then the TearDownSuite never runs, which could lead to the VM not being destroyed & could lead to dangling/costly VMs.

Is this by design? If so, how could I go about solving my issue.

[glesica]

Would it make sense to let the setup finish and then have a test that runs immediately afterward and asserts that the environment is configured correctly? That being said, it seems reasonable that the teardown should at least run optionally if setup fails.

[AutomateAaron]

@glesica the issue with doing it in the first test is I need the ability to pick and choose which tests I run (Some may take a long time).

I could add this check to the SetupTest. But, that's not an amazing solution because it leads to the tests being run over and over again, which is probably fine in my case, but I could imagine that being a problem.

Another option is that if you need to FailNow() during the setup you manually defer the execution of the TearDownSuite something like:

if err != nil {
	defer suite.TearDownSuite()
	suite.T().FailNow()
}

But, this doesn't rub me as an amazing solution either since it requires manually calling TearDownSuite which could lead to accidentally calling it twice or etc. But, I'll let you decide your own feelings on this matter.

Edit: Even worse, the way it currently sits you have no way to truly defer the execution of a teardown function call in SetupSuite. You can't defer in the SetupSuite cause then it'd get called before the tests execute. And you can't just use TearDownSuite because you can't guarantee that it will run if there's, for example a panic.

[talha0324]

Any fix or a good workaround for this?

[AutomateAaron]

@talha0324 I believe this issue was resolved with #931

[sneko]

For me this issue is still relevant. See https://github.com/stretchr/testify/issues/1123