One handler test to rule them all

http://www.wired.com/images_blogs/wiredscience/2011/12/gollum.jpg

Setting to needs review so you can see it explode

What I found in the original patch. I changed some of that in my.

+++ b/lib/Drupal/views/Tests/Handler/HandlerAllTest.phpundefined
@@ -0,0 +1,55 @@
+    foreach (views_fetch_base_tables() as $base_table) {

should be $base_table =>$info (or something like that)

+++ b/lib/Drupal/views/Tests/Handler/HandlerAllTest.phpundefined
@@ -0,0 +1,55 @@
+              $view->addItem('default', $type, $field);

This is lacking the $base_table. AND default is not always a valid plugin ID is it?

+++ b/lib/Drupal/views/Tests/Handler/HandlerAllTest.phpundefined
@@ -0,0 +1,57 @@
+              $view->addItem('default', $type, $field);

Is still going to fail... It needs 4 items

#8: one_test_rule_them_all-8.patch queued for re-testing.

+++ b/lib/Drupal/views/Tests/Handler/HandlerAllTest.phpundefined
@@ -0,0 +1,57 @@
+    $object_types = array_keys(View::viewsObjectTypes());

Offcourse this fails ;)

viewsObjectTypes...

I did some serious debugging and I think this test catches a couple of bugs.
I used the "debug" script on the bottom.

Everything goes wrong in $view->execute.
Something is wrong with the filter plugins.
In my test I changed:

if (isset($field_info[$type]['id'])) {
to
if (isset($field_info[$type]['id']) && $type != 'filter') {

That makes the system happy but some other errors appear (with base table: users)

1) 'Missing handler: users langcode argument'
2) Undefined offset: 1 Notice GroupwiseMax.php 210 Drupal\views\Plugin\views\relationship\GroupwiseMax->left_query()
3) 'Missing handler: sort'

It's posisble they are all related

      debug('New loop');
      debug('Base table: ' . $base_table);

      $view = entity_create('view', array('base_table' => $base_table));

      // Go through all fields and there through all handler types.
      foreach ($info as $field => $field_info) {
        // Table is a reserved key for the metainformation.
        if ($field != 'table') {
          foreach ($object_types as $type) {
            if (isset($field_info[$type]['id']) && $type != 'filter') {
              debug('type and field: ' . $type . ' and ' . $field);
              $view->addItem('default', $type, $base_table, $field);
            }
          }
        }
      }

      debug('done adding');

Ok one bug found:

  // language
  $data['users']['language']['moved to'] = array('users', 'langcode');
  $data['users']['langcode'] = array(
    'title' => t('Language'), // The item it appears as on the UI,
    'help' => t('Language of the user'),
    'field' => array(
      'id' => 'user_language',
      'click sortable' => TRUE,
    ),
    'sort' => array(
      'id' => 'standard',
    ),
    'filter' => array(
      'id' => 'node_language',
    ),
    'argument' => array(
      'id' => 'node_language',
    ),
  );

The node_language argument plugin doesn't exist.
That line is added in: http://drupalcode.org/project/views.git/commitdiff/5203f9c5ddf2e5703a97e...
But I'm not sure I understand why it has to be there if there is no actual plugin handling it...

2) and 3) are related to the same bug. That bug is caused by this piece of code in users.views.inc

  // uid
  $data['users']['uid_representative'] = array(
    'relationship' => array(
      'title' => t('Representative node'),
      'label'  => t('Representative node'),
      'help' => t('Obtains a single representative node for each user, according to a chosen sort criterion.'),
      'id' => 'groupwise_max',
      'relationship field' => 'uid',
      'outer field' => 'users.uid',
      'argument table' => 'users',
      'argument field' =>  'uid',
      'base'   => 'node',
      'field'  => 'nid',
    ),
  );

In "function left_query($options) {" the printed $options array equals

array (
  'id' => 'uid_representative',
  'table' => 'users',
  'field' => 'uid_representative',
  'relationship' => 'none',
  'group_type' => 'group',
  'admin_label' => '',
  'label' => 'Representative node',
  'required' => false,
  'subquery_sort' => NULL,
  'subquery_order' => 'DESC',
  'subquery_regenerate' => false,
  'subquery_view' => false,
  'subquery_namespace' => false,
)

subquery sort is NULL which is bad as we do:

      // Add the sort from the options to the default display.
      // This is broken, in that the sort order field also gets added as a
      // select field. See http://drupal.org/node/844910.
      // We work around this further down.
      $sort = $options['subquery_sort'];
      list($sort_table, $sort_field) = explode('.', $sort);

I hope this enough info :)

For me this is rtbc but dawehner wants input from the others. As this is a duplicate of #1754206: Add one test that enables all modules and adds all filters Tim must be into this as well. I ran these tests locally and they go lightning fast so I don't see any performance issues on this one.

I'll rtbc this in 7 days if no one else did it.

#32: views-1777194-32.patch queued for re-testing.

Small nit from reading proposed patch...

+++ b/lib/Drupal/views/Plugin/views/relationship/GroupwiseMax.phpundefined
@@ -231,7 +233,7 @@ class GroupwiseMax extends RelationshipPluginBase {
       'argument',
-      $this->definition['argument table'], // eg 'term_node',
+      $this->definition['argument table'], // eg 'taxonomy_index',
       $this->definition['argument field'] //  eg 'tid'

Simple question... Does core documentation allow for in-line comments at the end of a line? I thought that the comment was required to go on the line above, ideally be a sentence and end in a period.

Also, my understanding is that 'eg' should be written as 'e.g.'.

Let's do this

This looks good, a nice partner to the PluginInstanceTests!

Even so, I think this is still a good idea. Tests should maybe have some assertions?! :)

#47: views-1777194-47.patch queued for re-testing.

Committed!
http://drupalcode.org/project/views.git/commit/7152053