Phpunit preflight checks

[sandervanhooft]

I'd like to run some "pre-flight assertions" prior to running all other phpunit tests. Is there a way to do this?

Context: running a lot of integration tests, and I want to make sure the proper environment variables are available at the beginning of the full test run.

[avvertix]

I usually implement the setup() method in those tests and there I check for the existence of the environment variables. In case they are not found I do mark the test as skipped. This is the code I use:

protected function setUp()
{
   if (empty(getenv('ENV_VARIABLE'))) {
       $this->markTestSkipped('ENV_VARIABLE not configured for running integration tests.');
   }
}

Not sure if there are better approaches

[sandervanhooft]

@avvertix Yeah I was thinking the same, adding this to the setUp method in the parent BaseTestCase class.

But it seems a bit inefficient, as it runs on each test, while I only need this check once. For setting integration resource keys (ie. to specific payments), it may also be appropriate to check if the key results in an actual resolvable resource.

I came across this StackOverflow post here. The accepted answer is not what I'm looking for (also inefficient), but the custom bootstrap approach seems interesting. 🤔

[avvertix]

I actually use that code only in the tests that require checking environment variables and to be honest are not that much. I think you could handle the same scenario with a Trait, like how the RefreshDatabase trait work, which is only invoked if added to the class. This should probably reduce some of your concern

[sandervanhooft]

Agreed!

I have currently defined some getter helpers on the BaseTestCase class for these environment variables. Would be interesting to refactor these into a trait and add additional one-time assertions there. So two options:

1. use a custom phpunit bootstrap for a real pre-flight check, which is a bit more complex, but most efficient.
2. use Traits to add the pre-flight checks to classes where applicable. Slightly less efficient, but still clean.

Thanks @avvertix for your help sorting this one out!