Speed up tests by only installing the views used by that tests

Shouldn't this be generic across configurables? What makes Views super unique?

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/FilterDateTest.phpundefined
@@ -42,13 +49,21 @@ function setUp() {
+  protected function testDateFilter() {
+    $this->_testOffset();
+    $this->_testBetween();
+    $this->_testUiValidation();
+  }

< 3

+++ b/core/modules/views/lib/Drupal/views/Tests/Language/LanguageTestBase.phpundefined
@@ -7,25 +7,18 @@
+abstract class LanguageTestBase extends ViewUnitTestBase {

yeah!

+++ b/core/modules/views/lib/Drupal/views/Tests/Plugin/ArgumentDefaultTest.phpundefined
@@ -112,16 +110,18 @@ function testArgumentDefaultNoOptions() {
+    $options = $view->display_handler->getOption('arguments');
+    $options['null']['default_argument_options']['argument'] = $random;
+    $view->display_handler->overrideOption('arguments', $options);

@@ -137,13 +137,4 @@ function testArgumentDefaultFixed() {
-    $view = $this->createViewFromConfig('test_argument_default_fixed');
-    $view->displayHandlers['default']->display['display_options']['arguments']['null']['default_argument_options']['argument'] = $this->random;

This makes it's also way easier to read.

+++ b/core/modules/views/lib/Drupal/views/Tests/Plugin/PagerTest.phpundefined
@@ -133,48 +140,35 @@ public function testNoLimit() {
+    for ($i = 0; $i < 23; $i++) {

There is some conspiracy going on.

+++ b/core/modules/views/lib/Drupal/views/Tests/UI/StorageTest.phpundefined
@@ -26,9 +33,10 @@ public static function getInfo() {
+    $view_name = 'test_view';
...
-    $path = "admin/structure/views/nojs/edit-details/{$view->storage->get('name')}";
+    $path = "admin/structure/views/nojs/edit-details/$view_name";

You seemed to have changed every instance of it, so cool!

+++ b/core/modules/views/lib/Drupal/views/Tests/ViewExecutableTest.phpundefined
@@ -148,27 +147,18 @@ public function testDisplays() {
-    // Manipulate the display variable to test a previous bug.
-    $view = $this->getView();
-    $view->preview();
...
-    $view->destroy();
-    $this->assertViewDestroy($view);

It's a good question whether testing for previous bugs should be part of the tests or not, but personally i would vote for yes, as it doesn't cost us much.

+++ b/core/modules/views/lib/Drupal/views/Tests/ViewTestData.phpundefined
@@ -18,6 +20,50 @@
+      $target_storage = drupal_container()->get('config.storage');

I had some similar code before (using the container in the test enviroment) and wasn't sure whether $this->container/drupal_container() is the right one to use, but for sure just the second one works without issues.

+++ b/core/modules/views/lib/Drupal/views/Tests/ViewTestData.phpundefined
@@ -18,6 +20,50 @@
+        foreach ($source_storage->listAll() as $config_name) {

Should we use the 'views.view' prefix here already? Technically it doesn't change but it might make it easier to get the code.

This seems OK to me, especially in the context of test optimization. It would be nice if we could figure out a way to actually use config_sync_get_changes() to generate the list, but it doesn't really make sense given what we're trying to do. There was one minor little thing in the code I wondered about.

+++ b/core/modules/views/lib/Drupal/views/Tests/ViewTestData.phpundefined
@@ -18,6 +20,50 @@
+    $views = array();
+    while ($class) {
+      if (property_exists($class, 'testViews')) {
+        $views = array_merge($views, $class::$testViews);
+      }
+      $class = get_parent_class($class);
+    }

Not sure I get the point of the array_merge() here since you hardcode $views to be an empty array above? Seems like you could just as easily do $views = $class::$textViews.

Haven't reviewed this myself, but just wanted to note that I added the underscore-prefixed method names to #1856630: [Change notice] [META] Rename Views methods to core standards, in case those raise any committer eyebrows.

Looks good to me. Committed/pushed to 8.x. Does this need a change notice for Views contrib test writers?

Change notifications have not been written for much larger API changes than this. I did try to introduce the idea, but...
http://drupal.org/list-changes/views

I guess we could file the change notice issues against views module in contrib..

is the 7.x to 8.x change notice for Views just going to be "HAHAHAHAHAHAHAHAHA"?

-webchick

So, I talked about this in IRC with berdir, webchick, etc. in IRC. Let's called this fixed, because we're changing how we do something that's new to D8 Views tests anyway. However, in general, we probably should come up with some change notifications for Views API changes, and henceforth let's set the issue back to active, tag for change notification, but not mark it critical, since it's a contrib API change rather than a core one. We can always decide we don't need a change notification for something.