Would be worth fallback to 0 instead of an empty string as the value?

agreed. For now, I have updated PR accordingly.

@felixarntz Do we need to set an empty value here?

Two things about this function:

• I would say the get in the name is a bit confusing, since it filters an existing input variable rather than getting a distinct value from somewhere. So I think a better name would be perflab_filter_valid_modules(). Or, we change this implementation to just be for a single module, e.g. perflab_is_valid_module( $module ), and then you could call it via array_filter( perflab_get_active_modules(), 'perflab_is_valid_module' ).
• Why is there a default? I would say this should rather be a required parameter, especially since calling it without any value is pointless since it would always just return the empty array then.

Thanks for the feedback.

I like the perflab_is_valid_module( $module ) approach instead of the function name change. Now we should have passed a valid module slug. I have updated unit tests according to these changes.

See above, these assertions should be using assertFalse or assertTrue based on the alternate return type.

Also, it would be more efficient to combine these two tests into one. Both could use the same @dataProvider, you could include the empty string in there, and then every data set could also include the expected true or false. You could use assertSame for that, similarly to how you have it below for the perflab_can_load_module tests.

Also it would be great if you could use the same method name for the data provider method, except replacing test_ with data_ (see other comment below).

Thanks for the feedback. I removed the empty module test and merged it into test_perflab_is_valid_module so it tests all scenarios. For this test, I use @dataProvider data_perflab_is_valid_module because we can't test an empty module in test_perflab_can_load_module test.