@jjgrainger @vishalkakadiya Regarding the problem that the test plugin code never runs in the unit tests, the issue is that the test plugin is never actually loaded. And we shouldn't force it to load generally via the test bootstrap file as that would pollute other tests (see my comment in the review above).

Since plugins are only loaded once, very early in the WordPress load cycle, we have to find ways to write test plugins so that they can be loaded on demand in the test suite without polluting global scope.
Here's one idea that could work:

• We could write every test plugin as a plugin that adds nothing to the global scope that can't be unset (e.g. it's okay to add hooks, or modify a global variable, but it's not okay to introduce functions or classes).
• Basically this means that every test plugin we write should only ever use closures, never named functions. And all it should do to the global scope is add actions or filters, using closures for the callbacks. This way, everything that the plugin does can be reset without disrupting other subsequent tests.
• This way, in any test that needs to simulate this plugin being active, we can require the plugin main file (not require_once). As long as it doesn't define any functions or classes, we can load it multiple times, in multiple tests. And any hooks that loading the plugin adds will be reset afterwards (as all WordPress hooks are reset automatically after each test).
• Of course this wouldn't work as a general requirement for plugins, but since we're only speaking about the test plugins for this repository to use in unit tests, I think that's a reasonable requirement.

Also see my related review feedback above, we should use separate test single-file plugins per individual check that we test, otherwise, if we have a single plugin with all errors, things will get messy and they may conflict with each other. We should be able to change the test plugin with errors that we have so far to make it two separate plugins and have both of those plugins satisfy the above requirements in order not to irrevocably pollute global scope.

Thanks @felixarntz the feedback here and the discussions with @joemcgill on Slack have been helpful here!

I've gone over the changes requested and made the updates to the test plugins based on your feedback. This has been helpful in cleaning things up and avoiding issues around loading the plugins for testing.

The changes I've made has got test working but there are a couple of things I want to highlight.

• When trying to 'activate' the test plugin for this check the Force_Single_Plugin_Preparation would throw an exception because the plugin isn't recognised. This error comes from the validate_plugin() call because the test plugin does not exist in the array returned by get_plugins(). The way I've worked around this is by using the Plugin Checker plugin as the check context as the test plugin file exists within this plugin.
• After making all the changes I still faced the same issue where the script being enqueued by the test plugin would never end up in the wp_scripts()->done array. To resolve this I have also included the wp_head() and wp_footer() calls along with wp_enqueue_scripts() in the Enqueued_Scripts_Size_Check class. I haven't looked deeper into this to determine if this is the correct approach or there is a different way to resolve this.

Let me know if you have any questions or feedback on this.

Thanks

Thanks @felixarntz I've updated the PR based on the feedback. This is ready for review