SGTM.

For the images, we may want to shrink them down to speed up the tests as well.

Otherwise, the only reason for a /tests directory would be to introduce test suites for combinations of plugins as discussed in #1012 (comment) and #1262 (comment). But seeing as we don't have that now, we can always add it back later if need be. However, as it stands right now the Enhanced Responsive Images and Embed Optimizer plugins do not have a strict plugin dependency on Optimization Detective. Nevertheless, they bootstrap Optimization Detective (and Image Prioritizer) in order to test their integrations which are available when they are active. It would be a bit better if the test suites for these plugins could run without the other optional plugins active, and then run again with these plugins active. This would ensure they work as expected in both cases. So this could be a case where a /tests directory could be used: There could be test suites in /tests/embed-optimizer-with-optimization-detective and /tests/auto-sizes-with-image-prioritizer which which are configured to bootstrap the multiple plugins, run the tests for them all, and then run any additional tests written specifically to test their integrations. cc @joemcgill

Makes sense to me. Regarding a combination of plugins, if we want to test that, I think the /tests directory is fine, however for the more specific case of testing a plugin with its dependency, I don't think we need /tests. The purpose of those tests will probably be to test functionality of the dependent plugin while the dependency plugin is active, so I think this should rather go into the specific plugin's tests directory. It could be a second test suite for that plugin, where the dependency (e.g. Optimization Detective) is active.