Enable blocks in testing profile and/or Classy

Testing profile should remain light weight for speed sake in my opinion

I don't know. It's really strange DX that every module that wants to test it's own UI has to manually install blocks.

Not that it would help people right away, but we could add something like this.

We could always add a 'testing_with_blocks' profile that enables block module and places the blocks needed by contrib in classy for their tests.

That way, tests that need those blocks can use that profile, while tests that need speed don't have to.

+++ b/core/modules/simpletest/src/WebTestBase.php
@@ -445,6 +445,17 @@ protected function drupalPlaceBlock($plugin_id, array $settings = array()) {
+  protected function enableLocalActionsAndTasksBlocks() {
+    if (!$this->container->get('module_handler')->moduleExists('block')) {
+      $this->container->get('module_installer')->install(['block']);
+    }
+    $this->drupalPlaceBlock('local_tasks_block');
+    $this->drupalPlaceBlock('local_actions_block');
+  }

Diggit. So a test class then has to do two things: 1) Enable block module, 2) call enableLocalActionsAndTasksBlocks().

Do we maybe call that from WebTestBase::setUp()? Then test classes still have to declare their use of block menu, but then they can override enableLocalActionsAndTasksBlocks() as needed.

1. I'm still confused that we provide a theme in core that you cannot actually interact with by default.
2. I think I'm leaning towards using the default theme for anything that does UI tests. It would be nice if WebTestBase let me pick the default theme as easy as the install profile. :/

Can we place blocks by default for Classy in the standard profile

Themes do not provide blocks.
Profiles do.
And standard absolutely places these blocks by default, or Drupal would be completely broken.

Is protected $profile = 'testing_with_blocks'; really that much easier than $this->placeSomeBlocksYo();?

@mdrummond #9: The reason we're in this situation is because menus, tasks, and actions are now blocks and you can place them anywhere, which means they're not placed by default.

Basically there are two answers to this issue:

1) It's not a problem. In your test class, enable block module and have code that places the blocks explicitly. I actually like this approach because of speed but mostly the explicit declaration of dependencies.

2) You have 10,000 tests already and it would be a super-duper hassle to change all these tests to explicitly place menu blocks. In this case, we should make the testing profile behave as it did before, by causing the testing profile to place the blocks on install.

If we split the difference we might have testing profile with its old behavior, and testing_no_dependencies with the new behavior. testing_config_import almost fits this bill, except for the name, and I'd rather it be Classy theme to be consistent with testing.

I think by this point this is a won't fix. Contrib tests should probably explicitly place any blocks they rely on for testing, just the same way core tests do, and contrib tests that already exist for 8.0.x will already have worked around this.

Closing since contrib has gotten along fine in the meantime