Replace exported views in tests with config files

+++ b/lib/Drupal/views/Tests/Field/HandlerFieldFieldTest.phpundefined
@@ -202,34 +202,14 @@ class HandlerFieldFieldTest extends FieldTestBase {
+      $handler->display_handler->display->display_options['fields'][$field['field_name']]['id'] = $field['field_name'];
+      $handler->display_handler->display->display_options['fields'][$field['field_name']]['table'] = 'field_data_' . $field['field_name'];

$handler doesn't exist in this local scope ... you probably mean $view

+++ b/lib/Drupal/views/Tests/User/ArgumentValidateTest.phpundefined
@@ -87,34 +87,9 @@ class ArgumentValidateTest extends UserTestBase {
+  ¶

just some whitespace

+++ b/lib/Drupal/views/Tests/ViewTestBase.phpundefined
@@ -382,51 +383,27 @@ abstract class ViewTestBase extends WebTestBase {
+   * Creates a new View instance by loading config data and calling create
+   * instead of loading the view normally.

Even there is a 80 chars limit for the first sentence, it's not that important for me, because it describes detailed what the function does.

+++ b/lib/Drupal/views/Tests/Field/HandlerFieldFieldTest.phpundefined
@@ -202,34 +202,14 @@ class HandlerFieldFieldTest extends FieldTestBase {
+      $handler->display_handler->display->display_options['fields'][$field['field_name']]['id'] = $field['field_name'];
+      $handler->display_handler->display->display_options['fields'][$field['field_name']]['table'] = 'field_data_' . $field['field_name'];

$handler doesn't exist in this local scope ... you probably mean $view

Some of these files have that weird
core: '8' VS core: { } and human_name: '' VS human_name: { }mixup.

Why does views have so many api versions!

The human_name: {} and tag: {} are causing most of these failures.
Also, views.view.test_view_fieldapi.yml doesn't exist?

So, we have tests/views_test/config and tests/default_views now? Why not just use the first one?

So, we have tests/views_test/config and tests/default_views now? Why not just use the first one?

We have two seperate use cases for now. First: Use the views in the UI, second: use the views in API.
If we put all into the config directory basically all tests would require the views_test module to be enabled (you worked so hard to get rid of it if possible).

If we put everything into the default_views folder, we cannot any longer directly use that in the ui, though one thing what we could do
is to load and save the view and then start to edit the view.

It's weird seeing them not in a /config folder.
Another possibility is having an empty test module like 'views_test_config' only to contain these, that can be enabled in the usual way with public static $modules, and rename views_test to views_test_data.

Oh i like the suggestion of tim. What about doing views_test_views instead of views_test_data?

Okay, going to work on this.

Okay, here's an attempt to fix this all up.

I was able to really clean up createViewFromConfig() now that views_test_config is a real module.

And the interdiff.

Duh!

Oh wow. Fun with stupid bugs!

This was a bug in the original patch.

Fixed more failures.

Even more.

More fixes.

Less fails.

3 more fixes

Alright, I've had enough :)

Someone else will have to finish off those failures.

Some of the tests could be fixed by adding ->cloneView() but sadly i don't really understand why this helps in most cases.
For the translatable text for example unpackOptions might have changed the values already so unpackTranslatables might have a different result.

Please don't trust the interdiff that much, as it contains git-crap.

I think I understand why cloneView is necessary, but it's not optimal. I opened #1773778: Standardize on using $this->view in setUp(), $this->view->destroy in tearDown() as a follow-up.

Here's a different take on #34, with an interdiff against #31.

Shit, those failures are in HEAD.
http://qa.drupal.org/pifr/test/273938

Hopefully the last patch.

Famous last words.

Fixed those locally

Final tweaks. If this passes, please commit!

#1774278: Update views_test_data schema and variables is the follow-up for the schema

Removed the offending changes.

Tracked down the last bug.

Because both @damiankloip and I put in substantial time into this issue, I have a feature branch I'd like to merge in. I'll do that once it's RTBC by one of the VDC team.

Awesome!

Merged in! Whew, what a day.